- From: Justin Novosad <junov@google.com>
- Date: Thu, 18 Jul 2013 12:27:18 -0400
- To: "K. Gadd" <kg@luminance.org>
- Cc: whatwg <whatwg@lists.whatwg.org>
On Thu, Jul 18, 2013 at 3:18 AM, K. Gadd <kg@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 >
Received on Thursday, 18 July 2013 16:27:44 UTC