[whatwg] Hardware accelerated canvas

[Glenn Maynard]

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

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

4)  Auto-snapshot based on some heuristics.
>

These are mostly the same, and should be able to keep the majority of
draw-once apps from breaking without hurting draw-repeatedly apps (games,
animations).

The only reason I can think of switch renderers, instead of snapshotting,
is to deal with losing the context *mid*-render, while a script is still
drawing.  (That seems like a problem so rare as to be almost theoretical,
though.)

On Tue, Sep 4, 2012 at 12:02 PM, David Geary <david.mark.geary at gmail.com>wrote:

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

This is a huge assumption.  I seriously doubt that apps that draw to a
canvas just once are a minority.


> and we're already talking about a very rare occurrence in the first place
>

That's another big assumption.  From what I understand, this is a regular
occurance on mobile.

-- 
Glenn Maynard