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

Re: [whatwg] Hardware accelerated canvas

From: Ashley Gullen <ashley@scirra.com>
Date: Sun, 2 Sep 2012 18:13:03 +0100
Message-ID: <CAABs73i6yGLwOWOB9BgUW8g=k1a6u_6QCB7ZFB2J6g-Gf-CTpA@mail.gmail.com>
To: Erik Möller <emoller@opera.com>
Cc: "whatwg@lists.whatwg.org" <whatwg@lists.whatwg.org>
Why is it prohibitively expensive to handle a lost context automatically in
a canvas 2D?

Having written a 2D engine which supports this (albeit in DirectX), don't
you just need to recreate the surface, set up your render state again,
recreate any textures that were referenced, then continue? (In some
engines, this can amount to simply calling init() again)

WebGL's intent is just to expose OpenGL ES to javascript, and since OpenGL
ES makes you handle lost contexts yourself, so does WebGL.  I think
contrary to that the canvas 2D API should be kept simple and
straightforward to use, and handle lost contexts automatically.

Ashley


On 2 September 2012 10:05, Erik Möller <emoller@opera.com> 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<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<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 17:13:32 GMT

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