W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2010

[whatwg] Image resize API proposal

From: Robert O'Callahan <robert@ocallahan.org>
Date: Sat, 22 May 2010 22:03:39 +1200
Message-ID: <AANLkTimhmlzSmMQQEkDKmpXWxH_YNMh7kYbRrMo75bp-@mail.gmail.com>
On Sat, May 22, 2010 at 10:12 AM, David Levin <levin at google.com> wrote:

> 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.
>
>
1. Phones have GPUs now. You won't see new devices being built that can run
real Web browsers but don't have some kind of GPU, because the limiting
factor on hardware now is not silicon but power.
2. Your proposal depends on browsers that implement your new API. As a
browser developer, I would rather make canvas faster across the board than
implement new API.
3. The GPU results are largely because GPUs are massively parallel.
4. The Firefox results include time to unpremultiply data and premultiply it
again, all on the CPU. They don't indicate how long readback from the GPU
actually takes on that machine. Also:
4a) the cost of readback is proportional to the size of the scaled image, so
if your use case is scaling down images to small sizes, readback is cheap.
4b) you can easily read back and send one chunk of the scaled image at a
time

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100522/0973891d/attachment.htm>
Received on Saturday, 22 May 2010 03:03:39 UTC

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