LGTM1 given the consistency here with other platform APIs and the need to extend this in the future.
On Tue, Sep 5, 2023 at 8:39 PM Dale Curtis <dalecur...@chromium.org> wrote: > I wouldn't say it's urgent, but I would hope for feedback within a week or > two. Thanks! > > - dale > > On Sun, Sep 3, 2023 at 4:32 AM Sangwhan Moon <s...@chromium.org> wrote: > >> Thank you for filing this. If it is urgent, I could flag it as time >> constrained. >> >> On Aug 31, 2023, at 7:14, 'Eugene Zemtsov' via blink-dev < >> blink-dev@chromium.org> wrote: >> >> >> TAG review: https://github.com/w3ctag/design-reviews/issues/889 >> >> On Wed, Aug 30, 2023 at 9:50 AM Dale Curtis <dalecur...@chromium.org> >> wrote: >> >>> Alex, I assume you mean TAG's views on consistency regarding transfer >>> ergonomics? Otherwise >>> https://www.w3.org/TR/design-principles/#consistency is what we >>> followed here. We have not asked, given that we felt this was a small >>> performance improvement, with pre-existing ergonomics, and already has >>> Media WG approval. We can certainly file a TAG request, but as you know, >>> litigating minor features like this through TAG is unlikely to have a >>> timely resolution. >>> >>> Regarding Yoav's proposal above of a single boolean, that might make >>> sense today where we have a single transfer, but we expect more input >>> ArrayBuffers over time for some of these APIs, which would mean it becomes >>> all-or-nothing for developers. E.g., we are likely to accept arrays of >>> metadata, HDR data, etc. The boolean would mean they must transfer >>> everything, which may lead to them making temporary copies of smaller >>> buffers to get transfer effects on the larger ones. >>> >>> Daniel, sorry, that's just an oversight in the chromestatus entry. There >>> are tests added (here's the one for videoFrame): >>> >>> https://chromium-review.googlesource.com/c/chromium/src/+/4529012/17/third_party/blink/web_tests/external/wpt/webcodecs/videoFrame-construction.any.js >>> >>> - dale >>> >>> On Wed, Aug 30, 2023 at 9:19 AM Daniel Bratell <bratel...@gmail.com> >>> wrote: >>> >>>> In addition to Alex's question, I also noticed that you answered the >>>> web-platform-tests with a "no", which is a bit unexpected to me. Is there a >>>> reason this cannot or won't be tested in web-platform-tests? >>>> >>>> /Daniel >>>> On 2023-08-30 18:03, Alex Russell wrote: >>>> >>>> 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/Djuffi >>>>>>>>> n/1c8fac486ca9f402be85074166e89a16 >>>>>>>>> >>>>>>>>> Specificationhttps://www.w3.org/TR/webcodec >>>>>>>>> s/#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 >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ca4852cc-e0ab-4685-99d9-84d2f8316b90n%40chromium.org?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> -- >>>> 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/fbe4d8ba-2d6a-f085-6608-25a2eeef6d22%40gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fbe4d8ba-2d6a-f085-6608-25a2eeef6d22%40gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> >> >> -- >> 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/CAK8JDrF_jrf-1aRNk1AshPHDzUsiJeS3zoeuwXwuznZMpJxx_w%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK8JDrF_jrf-1aRNk1AshPHDzUsiJeS3zoeuwXwuznZMpJxx_w%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> -- 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/CAL5BFfX1Vd7t%3DpFtYTB0gojxEBL92Uaj73xt5o63FCTw5hRcZA%40mail.gmail.com.
