[whatwg] Hardware accelerated canvas

Glenn Maynard glenn at zewt.org
Tue Sep 4 10:20:52 PDT 2012

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,

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,

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

More information about the whatwg mailing list