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

Re: [whatwg] Hardware accelerated canvas

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 04 Sep 2012 12:43:11 -0400
Message-ID: <50462F9F.5030103@mit.edu>
To: whatwg@lists.whatwg.org
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 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.

Received on Tuesday, 4 September 2012 16:43:48 UTC

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