On 9/2/2012 5:36 PM, Glenn Maynard wrote:
On Sun, Sep 2, 2012 at 4:24 PM, Ian Hickson <i...@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
