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

Re: [whatwg] Hardware accelerated canvas

From: Glenn Maynard <glenn@zewt.org>
Date: Sun, 2 Sep 2012 13:22:25 -0500
Message-ID: <CABirCh_0d6wTjhWW0muLNb+LbAEJBGwoYERWBrF3F3EoD15paA@mail.gmail.com>
To: Ashley Gullen <ashley@scirra.com>
Cc: "whatwg@lists.whatwg.org" <whatwg@lists.whatwg.org>, Erik Möller <emoller@opera.com>
On Sun, Sep 2, 2012 at 12:13 PM, Ashley Gullen <ashley@scirra.com> wrote:

> 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)

That would erase the canvas, since you don't know its contents in order to
recreate it.

WebGL's intent is just to expose OpenGL ES to javascript, and since OpenGL
> ES makes you handle lost contexts yourself, so does WebGL.

If there was a way to make WebGL transparently handle context loss, they'd
have done it.  It's easily the most unpleasant part of WebGL and will
probably end up being the biggest source of bugs and failed interop (on
platforms where it happens).  WebGL makes you handle lost contexts yourself
because it's the only thing that can be implemented in practice.

It'd be easier on users with 2d canvases, since there's much less
unrestorable state (only the contents of the canvas, not textures, shaders,
and so on), but it would still be a major source of interop issues.

Glenn Maynard
Received on Sunday, 2 September 2012 18:22:53 UTC

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