Re: CfC: Should WebCodecs be exposed in Window environments?

Hi Mark, comments inline.

On Fri, Jul 16, 2021 at 12:46 PM Mark Watson <watsonm@netflix.com> wrote:

> I apologize in advance if the following question has been argued at length
> (I guess it probably has). In that case, please just point me to the
> discussion or just tell me to go away.
>

No worries, the thread has gotten so long it's hard for new voices to jump
in! More voices are welcome.

Unless I missed something, WebCodecs is an asynchronous API and so the
> question of whether the actual work takes place on the main thread or not
> (and thus whether it causes jank) is surely a quality-of-implementation
> issue, no ?
>

No, that would violate the spec. No-one is arguing for doing the
encoding/decoding itself on the main-thread. [1]

The concern isn't the encoding/decoding itself janking scrolling, but
scrolling janking the framerate of media pipelines laid on main-thread,
that should have been laid on a worker [2]. There's agreement on this [3].
The disagreement is over whether this concern warrants defaulting
(limiting) exposure to workers for all use cases.

It also seems trivial to polyfill a window implementation if only a worker
> implementation is provided.
>

Yes, both sides have pointed this out [3], and Dale Curtis did this in [4].

[1] https://github.com/w3c/webcodecs/issues/211#issuecomment-854185387
[2] https://github.com/w3c/media-source/issues/175#issuecomment-267699087
[3] https://github.com/w3c/webcodecs/issues/211#issuecomment-861057713
[4] https://github.com/w3c/webcodecs/issues/211#issuecomment-866330122


> ...Mark
>
> On Fri, Jul 16, 2021 at 8:17 AM Chris Cunningham <chcunningham@google.com>
> wrote:
>
>> Thanks Francois,
>>
>> On Fri, Jul 16, 2021 at 2:34 AM Francois Daoust <fd@w3.org> wrote:
>>
>>> For the sake of completion, I note that the process section quoted above
>>> also has "Groups should favor proposals that create the weakest
>>> objections. This is preferred over proposals that are supported by a
>>> large majority but that cause strong objections from a few people".
>>>
>>
>> In my reading, this does not describe our circumstances. While we have a
>> clear majority / minority mix, it is not the case that majority opinion is
>> less strongly held than that of the minority. Both sides have passionately
>> argued their positions.
>>
>>
>>> There seem to be areas that
>>> could still be explored or discussed, e.g. to:
>>>
>>> - assess whether the control queue can alleviate jank concerns:
>>> https://github.com/w3c/webcodecs/issues/211#issuecomment-879503390
>>
>>
>>> - better understand constrained devices:
>>> https://github.com/w3c/webcodecs/issues/211#issuecomment-880870815
>>>
>>> - clarify criteria that could make people change their mind:
>>> https://github.com/w3c/webcodecs/issues/211#issuecomment-861067041
>>>
>>> - or perhaps constrain the API somehow so that problematic usage that
>>> would likely jank the main thread would actually be forbidden on the
>>> main thread, while other usages on the main thread would remain
>>> possible?
>>>
>>> Francois.
>>>
>>
>> Most of these questions are for others in the thread, but I want to chime
>> in on the last one. Constraining the API differently in different settings
>> is unappealing. We've heard from developers in the GH issue that existing
>> differences between window and worker are a source of pain. Moreover, given
>> Chrome's position that main-thread jank is not material to all use cases
>> (see our earlier CfC position reply), it follows that the possibility of
>> such jank shouldn't motivate design restrictions.
>>
>> Chris
>>
>>

-- 
.: Jan-Ivar :.