- From: David Geary <david.mark.geary@gmail.com>
- Date: Mon, 3 Sep 2012 11:31:11 -0600
- 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