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

Re: [whatwg] Hardware accelerated canvas

From: David Geary <david.mark.geary@gmail.com>
Date: Mon, 3 Sep 2012 11:31:11 -0600
Message-ID: <CA+44znju5NmC0keyjWRL-fm_By3fdkYn7C6ygmVpem3CxZup4Q@mail.gmail.com>
To: Benoit Jacob <bjacob@mozilla.com>
Cc: whatwg@lists.whatwg.org, Erik Möller <emoller@opera.com>, Charles Pritchard <chuck@jumis.com>, Ian Hickson <ian@hixie.ch>, Glenn Maynard <glenn@zewt.org>
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.

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
>
Received on Monday, 3 September 2012 17:31:38 UTC

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