createImageBitmap's Promise resolving

[Kaiido]

What is the issue with the HTML Standard?

As has been reported in #10608, createImageBitmap doesn't queue a task to resolve its Promise while it's in parallel.

However the situation isn't as simple as just queuing a task since there is a discrepancy here, as can be seen in this test case I set up: https://jsfiddle.net/pnrsxk21/

In Chrome and Safari the Promise is actually resolved synchronously for all source types but Blob (which I suppose would end up in the file reading task source).

In Firefox however it seems that a task is indeed queued for every kind of source.

I suppose aligning on Firefox's behavior would make the most sense and be the easiest to spec and maintain, but I'm not entirely sure of all the implications here.

cc @whatwg/canvas

[annevk]

Can we imagine a future where more data is read in parallel from these other sources without that resulting in some kind of race condition? Like I think for canvas for instance you pretty much have to make a synchronous copy. Perhaps you could do it lazily, but it would get complex fast.

A lot of the other types also require synchronous checks on suitability.

As such, even if we specified Firefox's model, I think it just ends up giving people the data slightly later, but it won't actually present opportunities for a better implementation (e.g., more complex, but also more efficient).

Edit: I was somewhat naive in writing the above. There's a lot more involved in drawing these days and additional parallelism is definitely warranted.

I suppose the main argument in favor of Firefox's model is consistency. As someone using the API you won't have to care about how you invoke it, you always have to wait beyond the current task for an answer (unless it's one of the near-synchronous failures, which I assume do reject the promise end-of-task).

As what Firefox does also matches what the specification attempted to specify, correcting it in that direction + tests seems reasonable to me.