Revise processing model, fix queue size attributes by chcunningham · Pull Request #493 · w3c/webcodecs

chcunningham · 2022-05-16T22:54:31Z

A few changes

Updates process model to process control message queue entirely on the main thread. This aligns spec with Chrome, fixing Chrome vs spec: encoder.encodeQueueSize #494.
Moving ^that processing to the main thread means we need to be more explicit about when the loop is blocked/exited. For example, an implementation may block processing a decode() call when it finds the decoder is saturated by active decodes. Previously we elided description of this blocking behavior because the blocked loop lived on another thread, which was unobservable (beyond the queue size attributes). But with message processing happening entirely on the main (control) thread, we're motivated to be more explicit (we can't block scripts).
Named "codec" and "control" threads are removed to be more idiomatic with other W3C specs. WebAudio has named threads, but I've learned that isn't typical. This isn't strictly necessary, but it seems like a smart time to make the change (I'm re-writing all references to these threads anyway).

chcunningham · 2022-05-16T23:11:34Z

start with Chrome vs spec: encoder.encodeQueueSize #494
then read PR comment above

This first commit revises the processing model and updates AudioDecoder.configure() and AudioDecoder.decode() to use the new way. Will go further after getting some initial feedback.

chcunningham · 2022-05-16T23:11:44Z

@sandersdan FYI

chcunningham · 2022-07-02T07:56:36Z

@aboba @padenot, PTAL

chcunningham · 2022-07-27T17:55:42Z

@padenot has gone OOO for a bit, so planning to TBR for his review (he's already blessed the first round of change for AudioDecoder).

@dalecurtis, could you take a look at the ImageDecoder changes here. Should be no change at all to Chrome's behavior - just editorial refactoring to align spec:chrome. Happy to go through it on VC if you'd like.

dalecurtis

Seems to make things more complicated than necessary for ImageDecoder, but it's probably better to be consistent throughout the document on the processing model.

dalecurtis · 2022-07-27T19:52:08Z

+    instance. See [=[[control message queue]]=].
+
+: <dfn attribute for=ImageDecoder>[[message queue blocked]]</dfn>
+:: A boolean indicating when processing the


Currently there are no operations which can block the work queue for ImageDecoder. The only things close are reset() and track changes, both of which will abort the queue.

The constructor has an async step to configure the decoder, similar to how configure() works for the other interfaces. This gets queued as a control message and blocks any subsequent decode() until configure resolves. It may be that our impl is actually simpler than this, and I don't know that the blockage is really observable anyway, but it seemed nice to be consistent w/ the other configure() control messages in this way.

dalecurtis · 2022-07-27T19:55:09Z


 A <dfn>valid image MIME type</dfn> is a string that is a [=valid MIME type
-string=] and for which the `type`, per Section 3.1.1.1 of [[RFC7231]], is
+string=] and for which the `type`, per Section 3.1.1.1 of [[RFC9110]], is


Was this a typo before?

Bikeshed let me know that the original RFC was obsoleted by this new one.

chcunningham

Thanks @dalecurtis.

I definitely agree w/ your sentiment that this is more complicated than I'd make it were ImageDecoder a standalone thing.

chcunningham · 2022-07-28T03:49:36Z

+    instance. See [=[[control message queue]]=].
+
+: <dfn attribute for=ImageDecoder>[[message queue blocked]]</dfn>
+:: A boolean indicating when processing the


The constructor has an async step to configure the decoder, similar to how configure() works for the other interfaces. This gets queued as a control message and blocks any subsequent decode() until configure resolves. It may be that our impl is actually simpler than this, and I don't know that the blockage is really observable anyway, but it seemed nice to be consistent w/ the other configure() control messages in this way.

chcunningham · 2022-07-28T03:53:23Z


 A <dfn>valid image MIME type</dfn> is a string that is a [=valid MIME type
-string=] and for which the `type`, per Section 3.1.1.1 of [[RFC7231]], is
+string=] and for which the `type`, per Section 3.1.1.1 of [[RFC9110]], is


Bikeshed let me know that the original RFC was obsoleted by this new one.

chcunningham · 2022-07-28T20:55:02Z

Thanks everyone. @padenot, I'll go ahead and merge as TBR while you're OOO. Late feedback welcome.

@chcunningham