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

Re: [whatwg] Hardware accelerated canvas

From: Rik Cabanier <cabanier@gmail.com>
Date: Sun, 2 Sep 2012 20:04:14 -0700
Message-ID: <CAGN7qDC-ozxUfGYGOvfsfvWmGtHj7HYcaOx3QQsZF8FvPO0_=w@mail.gmail.com>
To: Charles Pritchard <chuck@jumis.com>
Cc: "whatwg@lists.whatwg.org" <whatwg@lists.whatwg.org>, Erik Möller <emoller@opera.com>, Glenn Maynard <glenn@zewt.org>, Ian Hickson <ian@hixie.ch>
On Sun, Sep 2, 2012 at 6:37 PM, Charles Pritchard <chuck@jumis.com> wrote:

> 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.
>

Safari, Mozilla and especially Chrome do much more than that. I assume IE
does too since it's based on Direct2D.
Compositing and clipping are much faster on hardware.


> 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.
>

Sprite sheets can be much faster on GPU's too. (Although that's probably
another case of drawImage)


>
> 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 agree that filters are something that could be accelerated with Canvas,
even on mobile GPU's (iOS Safari 6.0 has them)
It seems like a simple add-on and browsers that support css filters can
most likely reuse the CSS parsing and shader setup code.


>
> 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.
>
>
Received on Monday, 3 September 2012 03:04:42 UTC

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