On Thu, Jul 18, 2013 at 3:18 AM, K. Gadd <k...@luminance.org> wrote: > > > > > > > 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(). > > > > This is why I was confused then, since I was told on this list that > ImageBitmap was a solution for the problem of drawing subrectangles of > images via drawImage (since the current specified behavior makes it > impossible to precisely draw a subrectangle). :( > > This is a really good point and case. I was under the impression that the color bleeding prevention was to be solved with ImageBitmaps, but as you point out, it breaks down for cutting rectangles on the fly. Furthermore, I think there is also no good solution for synchronously cutting rectangles out of animated image sources like an animated canvas or a playing video. Two possible solutions that were brought up so far on this list:
a) have synchronous versions of createImageBitmap b) have a rendering option to modify drawImage's edge filtering behavior (either an argument to drawImage or a rendering context attribute) I took note of this concern here: http://wiki.whatwg.org/index.php?title=New_Features_Awaiting_Implementation_Interest > > > -kg >