- From: Kenneth Russell <kbr@google.com>
- Date: Wed, 16 Oct 2013 13:23:52 -0700
- To: Justin Novosad <junov@google.com>
- Cc: WHAT Working Group <whatwg@whatwg.org>, Kyle Huey <me@kylehuey.com>, Robert O'Callahan <robert@ocallahan.org>
On Wed, Oct 16, 2013 at 1:13 PM, Justin Novosad <junov@google.com> wrote: > > > > On Wed, Oct 16, 2013 at 3:53 PM, Robert O'Callahan <robert@ocallahan.org> > wrote: >> >> On Thu, Oct 17, 2013 at 6:35 AM, Kenneth Russell <kbr@google.com> wrote: >>> >>> Yes, right. That factory method is already spec'ed on the >>> WorkerGlobalScope [1]. It actually returns a Promise, so presumably >>> transferToImageBitmap would have to as well. >> >> >> The whole point of transferToImageBitmap is that it's really fast, so I >> don't see why it has to be async. > > > True. I also wonder why all of the currently spec'ed ImageBitmap creation > methods are async. I think asynchrony makes sense when creating ImageBitmaps > from blobs, image elements and video elements, which may not be in an > immediately accessible state, but creating an ImageBitmap from a Canvas or > canvas context (or a WorkerCanvas) could be immediate. It would be fine in my opinion for transferToImageBitmap to simply return an ImageBitmap. The suggestion to return a Promise was merely for symmetry with createImageBitmap. While the Promise returned from createImageBitmap(HTMLCanvasElement) can be fulfilled immediately, is it worth introducing a special overload with a different return type? -Ken
Received on Wednesday, 16 October 2013 20:24:16 UTC