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

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.

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 ?

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

...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
>
>