- From: Justin Novosad <junov@google.com>
- Date: Wed, 17 Jul 2013 20:49:43 -0400
- To: Ian Hickson <ian@hixie.ch>
- Cc: WHAT Working Group <whatwg@whatwg.org>
On Wed, Jul 17, 2013 at 8:17 PM, Ian Hickson <ian@hixie.ch> wrote: > > On Tue, 18 Dec 2012, Kevin Gadd wrote: > > > > Sorry, upon reading over the ImageBitmap part of the spec again I'm > > confused: Why is constructing an ImageBitmap asynchronous? > > Because it might involve network I/O. > Just to be clear: According to the spec, image elements need to be loaded before they can be used as image sources for createImageBitmap. So I think the only case where it is super important to be asynchronous is for accessing data from blobs. In all other cases the benefits of asynchrony are rather marginal (UA can decode or do memcopies on a separate thread). I am wondering why it is important for image elements to be loaded. Is it in case the image element goes out of scope or the src attribute changes before the load completes? If that is the issue, the implementation can workaround that internally to ensure that the ImageBitmap is created from whatever resource was referenced by the source image when createImageBitmap was called. I think it would be nice to be able to avoid the JS red tape associated with chaining two async events (image onload -> createImageBitmap). > > On Mon, 15 Jul 2013, Justin Novosad wrote: > > > > It would be much more convenient if ImageBitmaps exposed their width and > > height in pixels as read-only attributes. I don't see any technical > > reason why we couldn't do that. Am I missing something? > > Nope. It is now added. Also density. > > Yay! Thanks. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' >
Received on Thursday, 18 July 2013 00:50:11 UTC