- From: Rik Cabanier <cabanier@gmail.com>
- Date: Sun, 2 Sep 2012 20:04:14 -0700
- 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