On Wed, Oct 16, 2013 at 1:13 PM, Justin Novosad <[email protected]> wrote: > > > > On Wed, Oct 16, 2013 at 3:53 PM, Robert O'Callahan <[email protected]> > wrote: >> >> On Thu, Oct 17, 2013 at 6:35 AM, Kenneth Russell <[email protected]> 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
