W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2012

Re: [whatwg] Hardware accelerated canvas

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 5 Sep 2012 01:07:36 -0700
Message-ID: <CA+c2ei8582o8W54JfZBxGTf0=1LCq2jz1Vdanast74mQvRoQYQ@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: whatwg@lists.whatwg.org, David Geary <david.mark.geary@gmail.com>
On Tue, Sep 4, 2012 at 10:15 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> So now our list is:
>
> 1)  Have a way for pages to opt in to software rendering.
> 2)  Opt canvases in to software rendering via some sort of heuristic
>     (e.g. software by default until there has been drawing to it for
>     several event loop iterations, or whatever).
> 3)  Have a way for pages to opt in to having snapshots taken.
> 4)  Auto-snapshot based on some heuristics.
> 5)  Save command stream.
> 6)  Have a way for pages to explicitly snapshot a canvas.
> 7)  Require opt in for hardware accelerated rendering.
> 8)  Authors use toDataURL() when they want their data to stick around.
> 9)  Context lost event that lets authors regenerate the canvas.
> 10) Do nothing, assume users will hit reload if their canvas goes blank.

11) Default to best-effort (current behavior), but allow opting in to
getting notifications about lost context, in which case the browser
would not need to do various tricks in order to attempt to save the
current state.

I.e. basically 4, but with the ability for the page to opt in to 9.

It sounds like no browsers do any such tricks right now, so
effectively the opt-in would be to just be notified. But possibly
browsers might feel the need to do various snap-shot heuristics on
mobile as they start to hardware accelerate there.

/ Jonas
Received on Wednesday, 5 September 2012 08:08:33 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:45 UTC