<br><br><div class="gmail_quote">On Mon, Jul 26, 2010 at 6:34 PM, Ian Hickson <span dir="ltr"><<a href="mailto:ian@hixie.ch">ian@hixie.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
On Thu, 20 May 2010, David Levin wrote:<br>
><br>
> Twice when this was brought up on whatwg developers out of the blue<br>
> mentioned that the image resizing was a useful thing for them (once early in<br>
> this thread and once long ago when canvas in workers was brought up).<br>
><br>
> In addition to that anecdotal evidence, here are several other places this<br>
> comes up which I can list quickly:<br>
><br>
> - For example, take Facebook. If I upload a huge photo to Facebook, it<br>
> seems to upload the whole thing and then resizes it on the server (down<br>
> to something much smaller than 1600 X 1200).<br>
><br>
> - This is similar for other social sites like dating sites or Orkut that<br>
> only allow a maximum size of photo. Typically, either they force the<br>
> user to resize the image (which is a horrible experience) or they resize<br>
> the image on the client using gears (with workers and canvas) or flash,<br>
> etc. (or canvas but for more than one browser that may hang the UI).<br>
><br>
> - Similarly Gmail now allows dragging images into email<br>
> (<a href="http://gmailblog.blogspot.com/2010/05/drag-images-into-messages.html" target="_blank">http://gmailblog.blogspot.com/2010/05/drag-images-into-messages.html</a>).<br>
> The full resolution image isn't necessary for this. It would be better<br>
> to have a resized image.<br>
><br>
> - Something like Google Docs or Wave which show real time participation<br>
> of other people typing would benefit from getting a thumbnail of an<br>
> inserted image to other people in the conversation. (One could envision<br>
> this for any real time chat/communication website.)<br>
><br>
> - When you upload photos to picasaweb from the Picasa client, it offers<br>
> to resize them to 1600X1200 before uploading them. Also, it offers an<br>
> option to upload a thumbnail first before uploading the bigger picture,<br>
> so the album can appear even quicker (just at a really low resolution).<br>
> Ideally, a website could do something similar.<br>
<br>
On Tue, 25 May 2010, David Levin wrote:<br>
><br>
> <a href="http://webkit.org/demos/canvas-perf/canvas.html" target="_blank">http://webkit.org/demos/canvas-perf/canvas.html</a><br>
><br>
> Firefox 3.7a4 (no D2D)<br>
><br>
> Direct image copy: 39ms<br>
> Indirect copy with (via ImageData): 160ms<br>
> Copy with 2x scale: 646.5ms<br>
> Copy with 0.5x scale: 42.5ms<br>
> Copy with rotate: 358ms<br>
><br>
> Firefox 3.7a4 (D2D)<br>
><br>
> Direct image copy: 115ms<br>
> Indirect copy with (via ImageData): 365.5ms<br>
> Copy with 2x scale: 246ms<br>
> Copy with 0.5x scale: 48.5ms<br>
> Copy with rotate: 100.5ms<br>
><br>
> Chrome 4.1.249.1064 (45376)<br>
><br>
> Direct image copy: 32.5ms<br>
> Indirect copy with (via ImageData): 207.5ms<br>
> Copy with 2x scale: 378.5ms<br>
> Copy with 0.5x scale: 27.5ms<br>
> Copy with rotate: 367ms<br>
><br>
> While the GPU does help in some scenarios, unfortunately it must still<br>
> take some time to do its work, so it doesn't enable us to do sync apis<br>
> that don't hang the UI.<br>
<br>
The logical conclusion is that we should make one of the following choices:<br>
<br>
1. Provide dedicated asynchronous APIs for this use case.<br>
For example, a method to go from an image URL to a Blob representing<br>
that image at a different size and/or rotation.<br>
<br>
2. Provide generic APIs for that can handle this use case amongst others.<br>
For example, porting the 2D canvas API to workers.<br>
<br></blockquote><div><br></div><div>I'd like to add I think there's a lot more enthusiasm for #2 </div><div>because there are many other situations that need to do</div><div>CPU intensive computing without bogging down the </div>
<div>main browser thread.</div><div><br></div><div>I'm not knocking #1. I'm just suggesting that there are</div><div>more champions for #2 since it solves problems for </div><div>more people.</div><div><br></div><div>
Any pointers to why this hasn't happened already?</div><div>I'm guessing there have already been giant debates</div><div>on how to share data between workers and the </div><div>main thread and or how to expose more services</div>
<div>to workers.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
3. Not address this use case (yet).<br>
<br>
For #1, my preference would be to add two methods to <img>, one to make<br>
<img> resize and rotate the image and then fire 'load' again, and one to<br>
obtain the current image as a Blob, much like toDataURL() on <canvas><br>
(where a similar toBlob() would also be useful).<br>
<br>
For #2, we'd need to provide an Image object (a non-DOM version of<br>
HTMLImageElement) and a Canvas object (a non-DOM version of<br>
HTMLCanvasElement) in workers.<br>
<br>
But unless we have a critical mass of browser vendors agreed on one of<br>
these approaches, we have to default to #3. Currently it seems only the<br>
Chrome team is especially interested in either #1 or #2.<br>
<br>
My recommendation, in the absence of enthusiasm from other browser<br>
vendors, would be for the Chrome team to experiment with #1 or #2. If I<br>
have misread the current situation and there is a willingness to implement<br>
#1 or #2 in more browsers, then please let me know. I'd be happy to spec<br>
one of those options. (#1 would be easy to do; #2 might take longer, since<br>
it is significantly more work.)<br>
<font color="#888888"><br>
--<br>
Ian Hickson U+1047E )\._.,--....,'``. fL<br>
<a href="http://ln.hixie.ch/" target="_blank">http://ln.hixie.ch/</a> U+263A /, _.. \ _\ ;`._ ,.<br>
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'<br>
</font></blockquote></div><br>