- From: David Levin <levin@google.com>
- Date: Fri, 21 May 2010 15:12:52 -0700
On Thu, May 20, 2010 at 6:24 PM, Robert O'Callahan <robert at ocallahan.org>wrote: > On Fri, May 21, 2010 at 12:50 PM, Maciej Stachowiak <mjs at apple.com> wrote: > >> I'd also love to hear from Mike Shaver and others from the original thread >> what they think of this API proposal. >> > > I think Shaver's feedback still applies: on any device with a GPU, we can > optimize canvas and/or rendering enough that scaling images is no problem on > the main thread. So this API would have a short useful lifetime ... possibly > negative. > There are a few issues here: 1. This only applies when you can accelerate with a GPU. Not all devices may support this. 2. This only applies to browsers that implement the acceleration with a GPU. When Mike Shaver mentioned this, he referred to a Windows version of Firefox. It is unclear if Firefox supports this on any other platform nor does it seem that all other browsers will support the accelerated canvas in the near-ish future. 3. The gpu results are due to the fact that the operation is done async from the call (which is great as far as not hanging the UI until you try to get the data out of the canvas, which leads to...). 4. Even with gpu acceleration, in order to use the result in an xhr, one has to get back the result from the gpu and this is a more expensive operation (because getting the data out of the gpu is slow) as indicated by the indirect copy results from Firefox and forces the completion of all of the operations that were being done async. In short the gpu accelerated canvas seems like it may be a ways away still on all platforms, and it is unclear if it will provide the desired benefit. dave -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100521/929357e3/attachment.htm>
Received on Friday, 21 May 2010 15:12:52 UTC