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

[Rik Cabanier]

On Wed, Jul 17, 2013 at 5:17 PM, Ian Hickson <ian at hixie.ch> wrote:

> 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.
>

Yes, please drop it since the HD methods are going away from the one
implementation.