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

[whatwg] Image resize API proposal

From: Chris Marrin <cmarrin@apple.com>
Date: Tue, 25 May 2010 06:32:55 -0700
Message-ID: <1B5FE695-0B18-4F9A-938F-7930DCBCCAF5@apple.com>

On May 24, 2010, at 2:09 PM, David Levin wrote:

> 
> 
> On Mon, May 24, 2010 at 1:40 PM, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> On Mon, May 24, 2010 at 1:21 PM, David Levin <levin at google.com> wrote:
> > We've discussed the leading alternate proposal optimized canvas (plus js to
> > read the exif information) and then get the bits out of canvas, but there
> > are several issues with this proposal including
> >
> > that not all browsers will have an implementation using the gpu that allows
> > web sites to use this and not hang the UI
> 
> This is a nonissue.  There's no point in speccing one feature to work
> around the fact that browsers haven't implemented another -- it makes
> more sense to just get the browsers to implement the latter feature,
> making the former moot.  Browsers look like they're moving toward GPU
> acceleration for everything now, and that has many more benefits, so
> we should assume that by the time they'd implement this API, they'll
> already be GPU-accelerated.
> 
> > that even if it was implemented everywhere, this solution involves readback
> > from the GPU which, as Chris mentioned, is generally evil and should be
> > avoided at all costs.
> 
> This I'm not qualified to comment on, though.  To the best of my
> knowledge, GPUs are magical boxes that make things go faster via pixie
> dust.  ;)
> 
> Thanks for your opinion. :)
> 
> Chris is qualified so are other people whom I've spoken to who have said the same thing, so using the gpu is not pixie dust in this particular scenario even though folks would like to be believe it so.

I didn't mean to say that GPU's are in general evil, just readback. GPU's can do magical things as long as you keep the data there. If your API were to return some abstract wrapper around the resultant image (Like ImageData), it would allow the bits to stay on the GPU. Then you can use the abstract API to pass the image around, render with it, whatever. There might still be some platforms that have to read the pixels back to use them, but not always. For instance, WebGL has API to take an ImageData and load it as a texture. If we see the image from that object are already in the GPU, we can use it directly or copy it (GPU-GPU copies are very fast) to the texture memory.

I'm not sure such a representation is appropriate for all the use cases here, but it would make image handler much faster in many cases.

-----
~Chris
cmarrin at apple.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100525/1b0c4c01/attachment-0001.htm>
Received on Tuesday, 25 May 2010 06:32:55 UTC

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