Re: [whatwg] Hardware accelerated canvas

On Mon, Sep 3, 2012 at 11:11 AM, Ian Hickson <ian@hixie.ch> wrote:

> There are ways to make it work without forgoing acceleration, e.g. taking
> regular "backups" of the canvas contents, remembering every instruction
> that was sent to the canvas, etc.
>

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.  You can't remember
every single instruction sent to the canvas--that would mean keeping every
drawImage source alive forever, too.  You have to be able to snapshot the
backing store and purge the draw list at some point (thus the readback in
b) of the original post).

I definitely disagree with Benoit's assumption that since WebGL can't come
up with anything better, Canvas can't either.  2d canvas and WebGL aren't
the same--WebGL has far more state to restore, some of which isn't directly
accessible in GLES (eg. depth buffers, IIRC).  It's definitely worth
evaluating every option before assuming that exposing context loss to
developers is really the only possible solution.

> If the choice becomes "follow the spec and don't hardware-accelerate
> > canvas" vs. "don't follow the spec and get orders of magnitude better
> > performance", I suspect I can guess the choice implementors will make
> > (implementors invited to speak for themselves, of course).
>
> This isn't an issue of the spec -- there is existing content that would be
> affected.
>

Again, there are approaches which can alleviate the common "draw once and
forget about it" cases.  For the benefits, I suspect the remaining content
breakage would fall well below the threshold people will tolerate, if it
came down to it.

On Sun, 2 Sep 2012, Rik Cabanier wrote:
> >
> > If there was a callback for context loss and if the user had set it, a
> > browser could throw the entire canvas out and ask for it to be
> > re-rendered if the canvas is shown again. This would even make sense if
> > you don't have a HW accelerated canvas.
> >
> > There would be no backward compatibility issue either. If the user
> > doesn't set the callback, a browser would have to do something
> > reasonable to keep the canvas bitmap around.
>
> This is an interesting idea... do other vendors want to provide something
> like this?
>

Also, would vendors actually be willing to shift existing content to this
slower path?  This is only a partial solution if implementations don't do
that part.

-- 
Glenn Maynard

Received on Monday, 3 September 2012 17:06:04 UTC