Re: [whatwg] Hardware accelerated canvas

On 9/2/2012 5:36 PM, Glenn Maynard wrote:
> On Sun, Sep 2, 2012 at 4:24 PM, Ian Hickson <ian@hixie.ch> wrote:
>
>> Realistically, there are too many pages that have 2D canvases that are
>> drawn to once and never updated for any solution other than "don't lose
>> the data" to be adopted. How exactly this is implemented is a quality of
>> implementation issue.
>>
> If the choice becomes "follow the spec and don't hardware-accelerate
> canvas" vs. "don't follow the spec and get orders of magnitude better
> performance", I suspect I can guess the choice implementors will make
> (implementors invited to speak for themselves, of course).  If I was
> playing a game rendered with Canvas and one browser had GPU-acceleration
> and one did not, I know for sure which one I'd choose.


Canvas GPU acceleration today is done via transform3d and transitions.
Yes, you are quite likely to notice the difference on a mobile device.

Other than that; there are some niche instances of using drawImage 
repeatedly, such as the Fish demo.

Largely, if you're thinking GPU acceleration, you're thinking WebGL.
And yes, you're going to notice a big difference there, too.

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.

> GPU-acceleration, so I wouldn't be surprised if implementations compromised
> on something like this.

What is really meant here by Canvas GPU acceleration?

Largely, the issues we have are with filters: an item that Vincent from 
Adobe and Rik have both brought up.

I've been frustrated a few times following Chrome development as they 
speed up the MS Fish Tank demo at the cost of ruining the performance of 
pen input/drawing programs.
It's bounced back and forth a few times now.

-Charles

Received on Monday, 3 September 2012 01:37:51 UTC