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

Re: [whatwg] Canvas in workers

From: Justin Novosad <junov@google.com>
Date: Wed, 16 Oct 2013 17:40:31 -0400
Message-ID: <CABpaAqTEcChNiR45he6O=AmyyUJCNtbNVAfVC58nKHXckRLJfg@mail.gmail.com>
To: Domenic Denicola <domenic@domenicdenicola.com>
Cc: WHAT Working Group <whatwg@whatwg.org>, Kenneth Russell <kbr@google.com>, Kyle Huey <me@kylehuey.com>, Robert O'Callahan <robert@ocallahan.org>
On Wed, Oct 16, 2013 at 5:29 PM, Domenic Denicola <
domenic@domenicdenicola.com> wrote:

> From: whatwg-bounces@lists.whatwg.org [whatwg-bounces@lists.whatwg.org]
> on behalf of Anne van Kesteren [annevk@annevk.nl]
>
> > On Wed, Oct 16, 2013 at 9:23 PM, Kenneth Russell <kbr@google.com> wrote:
> >> While the Promise returned from createImageBitmap(HTMLCanvasElement)
> can be fulfilled immediately, is it worth introducing a special overload
> with a different return type?
> >
> > Well if you want a synchronous method a promise is not going to cut it.
> However, please do not overload the existing method and actually provide a
> new one. Having one method that can be used both synchronous and
> asynchronous depending on its argument would be terrible.
>
> It's worth noting that immediately-fulfilled promises are pretty fast,
> since promises use microtasks.
>

Agreed, but even if the returned promise is immediately resolved, the
resolution notification (and the associated state transition) will be async
and will not happen at least until the current task (JS execution) ends,
which is what we would like to avoid by providing a synchronous API.  The
objective is to remove the complexity of having to use an async API in
cases where there is no benefit from being asynchronous.
Received on Wednesday, 16 October 2013 21:40:57 UTC

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