- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 18 Jul 2013 00:17:53 +0000 (UTC)
- To: whatwg@whatwg.org
On Tue, 18 Dec 2012, Kevin Gadd wrote: > > Is it possible to expose the width/height of an ImageBitmap, or even > expose all the rectangle coordinates? Exposing width/height would be > nice for parity with Image and Canvas when writing functions that accept > any drawable image source. > > Thanks for the prompt action here, this looks like a straightforward > solution. I've added height, width, and pixel density. Not sure what you meant by the other coordinates. 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. > I thought any decoding isn't supposed to happen until drawImage, so I > don't really understand why this operation involves a callback and a > delay. Making ImageBitmap creation async means that you *cannot* use > this as a replacement for drawImage source rectangles unless you know > all possible source rectangles in advance. This is not possible for > many, many use cases (scrolling through a bitmap would be one trivial > example). Yeah, it's not supposed to be a replacement for drawImage(). > Is it async because it supports using Video and Blob as the source? Mainly Blob, but maybe other things in the future. > I really love the feature set (being able to pass ImageData in is going > to be a huge boon - no more temporary canvases just to create images > from pixel data!) but if it's async-only I don't know how useful it will > be for the issues that led me to starting this discussion thread in the > first place. Can you elaborate on the specific use cases you have in mind? On Tue, 18 Dec 2012, Kevin Gadd wrote: > > How do you wait synchronously for a callback from inside > requestAnimationFrame? You return and wait for another frame. > Furthermore, wouldn't that mean returning once to the event loop for > each individual drawImage call you wish to make using a source rectangle > - so for a single scene containing lots of dynamic source rectangles you > could end up having to wait for dozens of callbacks. I don't understand. Why can't you prepare them ahead of time all together? (As in the example in the spec, for instance.) > Each time you wait for that callback, won't any pending drawing > operations to your canvas get flushed, resulting in the scene slowly > rendering onscreen? Right, don't draw anything until you're ready to draw it all. On Wed, 19 Dec 2012, Robert O'Callahan wrote: > > It seems to me a synchronous constructor that creates an ImageBitmap for > a subimage of another ImageBitmap (but not other kind of source!) will > be needed. What's the use case? On Tue, 18 Dec 2012, Rik Cabanier wrote: > > Did you mean to say a synchronous constructor? > Reading the new spec ( > http://www.whatwg.org/specs/web-apps/current-work/#imagebitmap), I still > fail to see how this is better than a drawimage with dx=dy=0 and > dw/dy=canvas width/height It's not. If you can use drawImage(), you should do so. BitmapImage is mainly to have a way to send an <img> to a worker so you can draw images in a worker, since workers can't have <img> objects. On Mon, 15 Jul 2013, Justin Novosad wrote: > > We've recently started implementing ImageBitmap in Blink. While writing > tests, we quickly realized that it is quite anoying that ImageBitmaps > are completely opaque objects. When converting animation tests that > used to use image elements over to using ImageBitmaps, we're ending up > having to pass triplets (ImagBitmap, width, height) where we used to > just have an image. > > 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. The density aspect of this might be pointless, given the failure of getImageDataHD(); if we're dropping that one, I'll drop this one at the same time. -- 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:18:18 UTC