[whatwg] Hardware accelerated canvas

Ian Hickson ian at hixie.ch
Sun Sep 2 14:24:01 PDT 2012

On Sun, 2 Sep 2012, Erik Möller wrote:
> 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.

Realistically, there are too many pages that have 2D canvases that are 
drawn to once and never updated for any solution other than "don't lose 
the data" to be adopted. How exactly this is implemented is a quality of 
implementation issue.

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

More information about the whatwg mailing list