[whatwg] Hardware accelerated canvas

[Ian Hickson]

On Mon, 3 Sep 2012, Glenn Maynard wrote:
> 
> As Erik said, taking a snapshot of the canvas is very expensive on some
> platforms.  If you're rendering a game in realtime, you never have a "time
> out" where you can tolerate an expensive readback.

If you're rendering a game in realtime, the issue doesn't come up. The 
most you'll be out is a frame.

You only have to back up the canvas when you notice it's not being updated 
and there's a chance the video card is going to get upset.


On Tue, 4 Sep 2012, Robert O'Callahan wrote:
> 
> I have to say though, we've been shipping 2D canvas with the 
> context-loss problem to millions of users for a couple of years now and 
> I don't recall seeing any bug reports about it. And it's the sort of bug 
> users would notice if it happened.

This suggests that we don't need to worry about it. Do we have any 
concrete metrics on how much of a problem this actually is? Is there a way 
to force it? (Changing video driver on Windows should do it, right? Is 
there a way to do that that isn't that heavy-duty? How about on Mac or X?)


On Mon, 3 Sep 2012, David Geary wrote:
> 
> I would like to see a provision for handling lost contexts along the 
> lines of Rick's proposal, perhaps with some underlying integration with 
> requestAnimationFrame() so application developers don't have to get 
> directly involved.

I think it makes a lot of sense for the browser to give the page an 
animation frame pronto if it has heard that the context has gone away. 
That doesn't require any special new features though.


On Mon, 3 Sep 2012, Rik Cabanier wrote:
>
> It's perfectly reasonable for an author to draw into a canvas once and 
> expect that the browser will manage it properly.

I agree.


On Tue, 4 Sep 2012, James Robinson wrote:
> 
> It's also important to note that unlike WebGL the only thing lost on a 
> lost context is the image buffer itself.  With WebGL, the page has to 
> regenerate a large number of resources (shaders, buffers, textures) 
> before it can render the next frame.  With canvas the page can just 
> start drawing.  Many applications redraw the entire canvas on every 
> frame so lost context recovery is identical to normal operation - just 
> draw the thing.  All other resources are managed and can be regenerated 
> by the browser without script intervention.

For applications where there is redrawing going on, I agree that it's 
basically a non-issue.

The point is 2D canvas is used for a lot of things that _never_ redraw. 
Even within the WHATWG sphere for example we have this:

   http://www.whatwg.org/issues/data.html

...which fetches data from the network and draws a graph. There's no 
redrawing going on.


On Tue, 4 Sep 2012, David Geary wrote:
> 
> 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. It's 
> straightforward to understand and to implement. It has the distasteful 
> downside of forcing some developers to add a few lines of code to their 
> existing apps, but if the apps are used and maintained is it really that 
> big of a deal?

"Used" and "maintained" are entirely orthogonal on the Web. Most pages are 
not maintained. Many actively-used apps are written by people who were 
contracted to write the app and who are no longer on retainer.


I think it's reasonable for us to add an event that fires on the <canvas> 
element, or on the CanvasRenderingContext2D object, when the canvas gets 
cleared because the video card is reset. I just don't expect it to be used 
very much, so I don't consider it a solution to all the problems we're 
discussing here. It's only a solution to some of the problems (namely, to 
those apps that only repaint dirty areas, and have authors who are aware 
that this problem can ever happen, and for which "just reload the page" 
isn't a sufficiently clean answer).

What should the event be called?

canvas.onforcerepaint?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'