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/CAPUDrwdB%3D1aFPLRcgoBYDPu6%2Bj7WUasdHsb05J2ReBNT302sYg%40mail.gmail.com.
