Thanks for all the feedback.
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:
1. 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.
2. We've presented a canvas solution that would utilize workers, but as
Mike Shaver (
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-March/025590.html)
indicated, different trade-offs among UAs supports the idea of specialized
API.
3. 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).
4. 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
- 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.
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.
dave
PS The proposed 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100524/54e5511a/attachment.htm>