[whatwg] Why can't ImageBitmap objects have width and height attributes? (and other e-mails)

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'