On Wed, Jul 17, 2013 at 5:17 PM, Ian Hickson i...@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.
