Re: [whatwg] Hardware accelerated canvas

On Mon, Sep 3, 2012 at 10:31 AM, David Geary <david.mark.geary@gmail.com>wrote:

> On Mon, Sep 3, 2012 at 7:21 AM, Benoit Jacob <bjacob@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.
>

No, we can't break the current implementation.
It's perfectly reasonable for an author to draw into a canvas once and
expect that the browser will manage it properly.


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

I'm unsure why you bring up requestAnimationFrame().
Can you elaborate?


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

Received on Monday, 3 September 2012 20:07:53 UTC