Re: [whatwg] Hardware accelerated canvas

On Tue, Sep 4, 2012 at 10:43 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 9/4/12 12:30 PM, James Robinson wrote:
>
>> Many applications redraw the entire canvas on every frame
>>
>
> This is already assuming there are "frames" involved.
>
> There are lots of applications (graphing comes to mind!) where you really
> want the canvas to be essentially a write-once-read-forever image.
>
> So perhaps the question should be: what can we do to make such
> applications robust?
>
> Options seem to include (just brainstorming; no feasibility issues
> considered so far):
>
> 1)  Have a way for pages to opt in to software rendering.
> 2)  Opt canvases in to software rendering via some sort of heuristic
>     (e.g. software by default until there has been drawing to it for
>     several event loop iterations, or whatever).
> 3)  Have a way for pages to opt in to having snapshots taken.
> 4)  Auto-snapshot based on some heuristics.
> 5)  Save command stream.
> 6)  Have a way for pages to explicitly snapshot a canvas.
> 7)  Require opt in for hardware accelerated rendering.
>
> Any others?
>
> Of the above, I don't think #5 and #7 are realistic, for what it's worth.
>  I haven't put enough thought into the rest yet to decide what I think
> about them.


I'm not crazy about any of them. They all seem like sticky wickets to me.
Implementation issues aside, they are at the wrong level of abstraction, so
they obfuscate the real reason for their existence.


>
>  I think it would be useful for some sorts of applications to be notified
>> when the image buffer data is lost so that they could regenerate it.  This
>> would be useful for applications that use a canvas to cache mostly-static
>> intermediate data or applications that only repaint dirty rectangles in
>> normal operation.
>>
>
> Or applications for which the output is basically static data and the
> canvas is the output medium.  Note that in such cases regeneration might be
> _very_ expensive, effectively requiring rerunning the whole
> compute-intensive part of the application.


Sure, but those use cases will be in the minority, and we're already
talking about a very rare occurrence in the first place, so the odds of a
very expensive regeneration on a lost context must be near Lotto levels.

I think it makes the most sense to add a context lost handler to the spec
and leave it up to developers to redraw the canvas. It's straightforward to
understand and to implement. It has the distasteful downside of forcing
some developers to add a few lines of code to their existing apps, but if
the apps are used and maintained is it really that big of a deal?


david


>
>
> -Boris
>
>

Received on Tuesday, 4 September 2012 17:03:32 UTC