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

[whatwg] Hardware accelerated canvas

From: Erik Möller <emoller@opera.com>
Date: Sun, 02 Sep 2012 11:05:49 +0200
To: "whatwg@lists.whatwg.org" <whatwg@lists.whatwg.org>
Message-ID: <op.wjz3jzqmj7kpr1@emoller-i7.bredbandsbolaget.se>
As we hardware accelerate the rendering of <canvas>, not just with the  
webgl context, we have to figure out how to best handle the fact that GPUs  
loose the rendering context for various reasons. Reasons for loosing the  
context differ from platform to platform but ranges from going into  
power-save mode, to internal driver errors and the famous long running  
shader protection.
A lost context means all resources uploaded to the GPU will be gone and  
have to be recreated. For canvas it is not impossible, though IMO  
prohibitively expensive to try to automatically restore a lost context and  
guarantee the same behaviour as in software.
The two options I can think of would be to:
a) read back the framebuffer after each draw call.
b) read back the framebuffer before the first draw call of a "frame" and  
build a display list of all other draw operations.

Neither seem like a particularly good option if we're looking to actually  
improve on canvas performance. Especially on mobile where read-back  
performance is very poor.

The WebGL solution is to fire an event and let the js-implementation deal  
with recovering after a lost context  
http://www.khronos.org/registry/webgl/specs/latest/#5.15.2

My preferred option would be to make a generic context lost event for  
canvas, but I'm interested to hear what people have to say about this.

For reference (since our own BTS isn't public yet).  
http://code.google.com/p/chromium/issues/detail?id=91308

-- 
Erik Möller
Core Gfx Lead
Opera Software
twitter.com/erikjmoller
Received on Sunday, 2 September 2012 09:06:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:10 GMT