W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2013

Re: [whatwg] Canvas in workers

From: Kenneth Russell <kbr@google.com>
Date: Wed, 16 Oct 2013 13:23:52 -0700
Message-ID: <CAMYvS2d03NTijCLBp1k95v4CExy5GkTPvzY4g1GpstERdkw4HA@mail.gmail.com>
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?

Received on Wednesday, 16 October 2013 20:24:16 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:12 UTC