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

Re: [whatwg] Hardware accelerated canvas

From: Rik Cabanier <cabanier@gmail.com>
Date: Mon, 3 Sep 2012 13:07:21 -0700
Message-ID: <CAGN7qDAAr1scaZ-L5nmTg=VHiMyLX2rPp3TKwwvE59gfNBmxVg@mail.gmail.com>
To: David Geary <david.mark.geary@gmail.com>
Cc: whatwg@lists.whatwg.org, Glenn Maynard <glenn@zewt.org>, Charles Pritchard <chuck@jumis.com>, Benoit Jacob <bjacob@mozilla.com>, Erik Möller <emoller@opera.com>, Ian Hickson <ian@hixie.ch>
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

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