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

Re: [whatwg] Hardware accelerated canvas

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 04 Sep 2012 13:15:46 -0400
Message-ID: <50463742.3070509@mit.edu>
To: David Geary <david.mark.geary@gmail.com>
Cc: whatwg@lists.whatwg.org
On 9/4/12 1:02 PM, David Geary wrote:
> Sure, but those use cases will be in the minority

What makes you say that?

Outside of games, I think they're a majority of the canvas-using things 
I've seen.

> I think it makes the most sense to add a context lost handler to the
> spec and leave it up to developers to redraw the canvas.

OK, yes, let's call that option 9.  And I'll add option 10: do nothing.

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.

Any other options, before we start trying to actually decide which if 
any of these might be workable?

Received on Tuesday, 4 September 2012 17:16:21 UTC

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