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

Re: [whatwg] Hardware accelerated canvas

From: Erik Möller <emoller@opera.com>
Date: Tue, 04 Sep 2012 20:42:45 +0200
To: "David Geary" <david.mark.geary@gmail.com>, "Boris Zbarsky" <bzbarsky@mit.edu>
Message-ID: <op.wj4jljuhj7kpr1@emoller-i7.gothenburg.osa>
Cc: whatwg@lists.whatwg.org
On Tue, 04 Sep 2012 19:15:46 +0200, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> 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?
>
> -Boris

It's important to discuss implementation details so we don't spec  
something that's not implementable on all platforms. That said we  
obviously should try to stay clear of specifying how things should be  
implemented and instead spec what end result we're after. There's little  
distinction from the end users point of view for example between  
snapshotting an saving the command stream.

Can we live with a weaker statement than a guarantee that the canvas  
content will be retained? Perhaps a "best effort" may be enough?
It's obviously in the vendors interests to do as good a job as possible  
with retaining canvas content, and I believe for example on Android it's  
possible to get notified before a power-save event will occur. That would  
enable us to do a read-back and properly restore the canvas (investigation  
needed). For applications that just cannot loose any data then canvas  
obviously isn't the best choice for storage. If we do have the context  
lost event then at least new versions of those applications can be sure to  
render out all their data to a canvas and move it over to an img while  
listening for the context lost event. Existing applications that cannot  
loose data... well, maybe that's a loss we'll have to accept, but by all  
means dazzle me with a brilliant solution if you have one.

JFYI I'd say by far the most common lost context scenario on desktop would  
be browsing to your driver manufacturers page, downloading and installing  
a new driver.

-- 
Erik Möller
Core Gfx Lead
Opera Software
twitter.com/erikjmoller
Received on Tuesday, 4 September 2012 18:43:19 UTC

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