Hey Eugene,
I'm a little worried that we're debating API shape here when there hasn't
been any guidance from the TAG on design consistency. Have you either asked
the TAG to weigh in (didn't see a review link in the Intent) or asked
Chromium (ex)TAG members to give the API a once-over?
Best,
Alex
On Thursday, August 24, 2023 at 9:45:42 AM UTC-7 Eugene Zemtsov wrote:
> > Can you clarify if this was in response to my questions or to
> Jonathan's?
>
> Yours.
> Sorry, I missed Jonathan's question.
>
> > Once an ArrayBuffer is transferred and detached, any further access
> will result in some sort of TypeError, right?
>
> Detached ArrayBuffers look like an empty ArrayBuffers.
> you can play with them using this code
>
> let ab = new ArrayBuffer(100);
> let ab2 = structuredClone(ab, { transfer: [ab] })
> ab is empty now
>
>
> On Thu, Aug 24, 2023 at 12:51 AM Yoav Weiss <yoavwe...@chromium.org>
> wrote:
>
>>
>>
>> On Wed, Aug 23, 2023 at 12:26 PM Jonathan Hao <p...@chromium.org> wrote:
>>
>>> Thanks for the clarification!
>>>
>>> On Tue, Aug 22, 2023 at 9:20 PM Eugene Zemtsov <ezemt...@google.com>
>>> wrote:
>>>
>>>> A transfer list is consistent with the approach taken by
>>>> structuredClone
>>>> <https://developer.mozilla.org/en-US/docs/Web/API/structuredClone> and
>>>> postMessage
>>>> <https://developer.mozilla.org/en-US/docs/Web/API/Worker/postMessage>.
>>>> And it's already a part of the WebCodecs spec.
>>>>
>>>
>> Can you clarify if this was in response to my questions or to Jonathan's?
>>
>>
>>>
>>>>
>>>> On Tue, Aug 22, 2023 at 7:36 AM Yoav Weiss <yoavwe...@chromium.org>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tuesday, August 22, 2023 at 11:08:24 AM UTC+2 Jonathan Hao wrote:
>>>>>
>>>>> Hi Eugene,
>>>>>
>>>>> Just to double check. Once an ArrayBuffer is transferred and
>>>>> detached, any further access will result in some sort of TypeError, right?
>>>>>
>>>>> Thanks,
>>>>> Jonathan
>>>>>
>>>>> On Wednesday, August 16, 2023 at 10:22:00 PM UTC+1 Eugene Zemtsov
>>>>> wrote:
>>>>>
>>>>> Contact emailsezemt...@google.com
>>>>>
>>>>> Explainerhttps://gist.github.com/Djuffin/1c8fac486ca9f402be85074166e8
>>>>> 9a16
>>>>>
>>>>> Specificationhttps://www.w3.org/TR/webcodecs/#dictdef-videoframeinit
>>>>>
>>>>> Summary
>>>>>
>>>>> This will allow detaching array buffers and using corresponding
>>>>> buffers inside VideoFrame, ImageDecoder, EncodedVideoChunk,
>>>>> EncodedAudioChunk, AudioData without a copy.
>>>>>
>>>>> Blink componentBlink>Media>WebCodecs
>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EMedia%3EWebCodecs>
>>>>>
>>>>> TAG reviewNone
>>>>>
>>>>> Risks
>>>>>
>>>>>
>>>>> Interoperability and Compatibility
>>>>>
>>>>> None
>>>>>
>>>>>
>>>>> *Gecko*: N/A (https://www.w3.org/2023/05/30-mediawg-minutes.html#t01)
>>>>> Change is too small to justify this effort. The change was discussed and
>>>>> approved by the w3c media working group.
>>>>>
>>>>> *WebKit*: N/A (https://www.w3.org/2023/05/30-mediawg-minutes.html#t01)
>>>>> Change is too small to justify this effort. The change was discussed and
>>>>> approved by the w3c media working group.
>>>>>
>>>>>
>>>>> I somewhat share Youenn's concerns about the API shape, but I'm not
>>>>> familiar with the examples this is supposed to be consistent with. Would
>>>>> it
>>>>> be possible to explore different API shapes in the explainer? (e.g. a
>>>>> boolean that detaches the input buffer after init would be my first
>>>>> choice)
>>>>> Typically we defer such questions to a TAG review. I'd hate to
>>>>> introduce significant delay at this point, but it might be possible to
>>>>> expedite this specific question and get it in front of them.
>>>>>
>>>>>
>>>>>
>>>>> *Web developers*: No signals
>>>>>
>>>>> *Other signals*:
>>>>>
>>>>> WebView application risks
>>>>>
>>>>> Does this intent deprecate or change behavior of existing APIs, such
>>>>> that it has potentially high risk for Android WebView-based applications?
>>>>>
>>>>> None
>>>>>
>>>>>
>>>>> Debuggability
>>>>>
>>>>> None
>>>>>
>>>>>
>>>>> Is this feature fully tested by web-platform-tests
>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>>>> ?No
>>>>>
>>>>> Flag name on chrome://flagsNone
>>>>>
>>>>> Finch feature nameNone
>>>>>
>>>>> Non-finch justificationNone
>>>>>
>>>>> Requires code in //chrome?False
>>>>>
>>>>> Tracking bughttps://crbug.com/1446808
>>>>>
>>>>> Estimated milestonesShipping on desktop120Shipping on Android120
>>>>>
>>>>> Link to entry on the Chrome Platform Status
>>>>> https://chromestatus.com/feature/5075602045927424
>>>>>
>>>>> --
>>>>> Thanks,
>>>>> Eugene Zemtsov.
>>>>>
>>>>>
>>>>
>>>> --
>>>> Thanks,
>>>> Eugene Zemtsov.
>>>>
>>>
>
> --
> Thanks,
> Eugene Zemtsov.
>
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ca4852cc-e0ab-4685-99d9-84d2f8316b90n%40chromium.org.
