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

[whatwg] Image resize API proposal

From: David Levin <levin@google.com>
Date: Mon, 24 May 2010 10:21:42 -0700
Message-ID: <AANLkTilhipgbKFldOhLNZv78lv5FI_r6ZbsWZq37mfby@mail.gmail.com>
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>
Received on Monday, 24 May 2010 10:21:42 UTC

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