<div>Thanks for all the feedback.</div><div><br></div>We've gotten into a lot of details about this proposal for image resizing (without hanging the UI), so I'd like to step back to a summary of the current state:<div>
<ol><li>We've presented several use cases which demonstrate many websites which would benefit from this feature. In fact, twice when this has come up, there have been web developers who mentioned a need for this. This mirrors my experience in which I've talked to at least 4 different teams that would use this functionality now if it were available.</li>
<li>We've presented a canvas solution that would utilize workers, but as Mike Shaver (<a href="http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-March/025590.html">http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-March/025590.html</a>) indicated, different trade-offs among UAs supports the idea of specialized API.</li>
<li>We explored 7 possible approaches for a more specialized api and then presented the one which seemed best (as well as mentioned the other 6 and the reasons that they were not our primary).</li><li>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 </li>
</ol></div><div><ul><ul><li>that not all browsers will have an implementation using the gpu that allows web sites to use this and not hang the UI</li><li>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.</li>
</ul></ul></div><div>At this point, it seems clear that the image resizing scenario is worth solving due to the number of places that it will benefit and that the api presented at the beginning of this thread solves it in a manner that allows the UA to optimize the operation.</div>
<div><br></div><div><font class="Apple-style-span" face="Helvetica" size="3"><span class="Apple-style-span" style="font-size: 12px; "><font class="Apple-style-span" face="arial"><span class="Apple-style-span" style="font-size: small;">dave</span></font></span></font></div>
<div><font class="Apple-style-span" face="Helvetica" size="3"><span class="Apple-style-span" style="font-size: 12px; "><font class="Apple-style-span" face="arial"><span class="Apple-style-span" style="font-size: small;"><br>
</span></font></span></font></div><div><font class="Apple-style-span" face="Helvetica" size="3"><span class="Apple-style-span" style="font-size: 12px; "><font class="Apple-style-span" face="arial"><span class="Apple-style-span" style="font-size: small;">PS The proposed</span></font></span></font> api is narrow (but it is just one api so perhaps that is good). In essence, that was part of the intent (following the guidance of the specialized api). For example, this api doesn't allow for getting an image for a pdf or word document. Also, the api makes it hard pull the thumbnail right out of the jpg when applicable (and this is a really nice optimization to avoid doing lots of unnecessary slow I/O). If folks have ideas about how to fix this, it would be interesting to hear.</div>
<div><br></div><meta charset="utf-8">