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

Re: [whatwg] Hardware accelerated canvas

From: Erik Möller <emoller@opera.com>
Date: Mon, 03 Sep 2012 10:55:24 +0200
To: "Glenn Maynard" <glenn@zewt.org>, "Charles Pritchard" <chuck@jumis.com>
Message-ID: <op.wj1xqmp8j7kpr1@emoller-i7.bredbandsbolaget.se>
Cc: "whatwg@lists.whatwg.org" <whatwg@lists.whatwg.org>, Ian Hickson <ian@hixie.ch>
On Mon, 03 Sep 2012 03:37:24 +0200, Charles Pritchard <chuck@jumis.com>  

> Canvas GPU acceleration today is done via transform3d and transitions.

I hope everyone are aware that this connection is just coincidental. The  
fact that one vendor decided to flip the hardware acceleration switch when  
there was a 3d-transform doesn't mean everyone will. Hardware acceleration  
and 3d-transforms are separate features. 3d transforms should be available  
in software rendering as well.

> Most [installed] GPUs are not able to accelerate the Canvas path drawing  
> mechanism.
> They are able to take an array of floats for WebGL, though.

It's true that there are no dedicated hardware for rendering paths in the  
GPUs of today, but they are very good at rendering line segments and  
triangle strips and paths can be triangulated. With some preprocessing  
paths can even be rendered directly using shaders  

> What is really meant here by Canvas GPU acceleration?

I can of course only speak for Opera, but we strive to hardware accelerate  
all parts of the drawing, and for canvas that also entails triangulating  
paths and batching to reduce the number of drawcalls. I.e. using an image  
atlas to draw several pieces in succession should give a good performance  
boost. Of course if we'd want to take it one step further then adding  
support at the API level for drawing multiple images would be good.

Erik Möller
Core Gfx Lead
Opera Software
Received on Monday, 3 September 2012 08:57:14 UTC

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