[whatwg] Hardware accelerated canvas

David Geary david.mark.geary at gmail.com
Mon Sep 3 10:31:11 PDT 2012


On Mon, Sep 3, 2012 at 7:21 AM, Benoit Jacob <bjacob at mozilla.com> wrote:

>
>
> ----- Original Message -----
> > What is really meant here by Canvas GPU acceleration?
>
> This means use GL/D3D to implement the 2D canvas drawing primitives; but
> what really matters here, is that this requires using a GL/D3D
> texture/surface as the primary storage for the 2D canvas drawing buffer.
>
> Because of the way that current GPUs work, this entails that the canvas
> drawing buffer is a /discardable/ resource. Erik's proposal is about
> dealing with this dire reality.
>
> Again, accelerated canvases have been widely used for a year and a half
> now. It's not realistic to expect the world to go back to non-accelerated
> by default now.

It seems to me that one way or another we have to break something. Canvases
drawn into once with no animation loop may go blank with GL-based hardware
acceleration, whereas most video games will not function properly without
it. I much prefer the former to the latter.

I agree that it's unrealistic to go back to non-accelerated canvas. I would
like to see a provision for handling lost contexts along the lines of
Rick's proposal, perhaps with some underlying integration with
requestAnimationFrame() so application developers don't have to get
directly involved.

HTML is a living specification and I believe developers would rather have
occasional breaks with backwards compatibility instead of severely reduced
performance.


david

>
> Benoit
>



More information about the whatwg mailing list