- From: Justin Novosad <junov@google.com>
- Date: Wed, 16 Oct 2013 17:40:31 -0400
- 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