On Tue, Sep 20, 2022 at 3:36 AM Yoav Weiss <yoavwe...@chromium.org> wrote:
> > > On Fri, Sep 16, 2022 at 11:19 PM Dale Curtis <dalecur...@chromium.org> > wrote: > >> Contact emailsdalecur...@chromium.org >> >> ExplainerNone >> >> Specificationhttps://github.com/w3c/webcodecs/issues/508 >> >> Summary >> premultiplyAlpha tells ImageDecoder to multiply the alpha channel into >> the RGB channels of decoded images. It was added to mirror the capabilities >> of ImageBitmapOptions, but in retrospect doesn't make sense. >> >> Feature has no observable effects in primary use cases (drawing), but may >> constrain implementations in suboptimal ways. E.g., requiring YUV be >> converted to RGB. See https://github.com/w3c/webcodecs/issues/508 for a >> more detailed description. Per consensus of WebCodecs spec editors and lack >> of usage (0.000000339% - 0.00000687% of page loads per a UseCounter in >> M105), we propose deprecating and removing this feature starting with M108. >> > > What would breakage look like? What would happen to callers who still pass > that option? > If they're just drawing the frames into canvas, webgl, etc there is no observable difference or breakage (this is the common use case) - since the draw stage takes care of any alpha blending. If they're accessing the raw pixels via VideoFrame::copyTo() they would notice that the alpha is no longer premultiplied. Depending on what the application is doing with the frames this may mean nothing (i.e., not using images w/ alpha, or didn't care about alpha) or it could result in color changes in the image. > > >> >> Blink componentBlink>Media>WebCodecs >> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EMedia%3EWebCodecs> >> >> TAG reviewNot applicable >> TAG review statusNot applicable >> >> Risks >> It's possible that there exists some client which was accessing raw pixel >> data in JavaScript may observe that the alpha channel is no longer >> premultiplied into RGB channels. Clients wishing for this functionality can >> either do the multiply themselves or use createImageBitmap() to do this. >> >> Interoperability and Compatibility >> >> >> >> *Gecko*: Positive Firefox co-editor supports removal. >> > > I don't know if we can consider this > <https://github.com/w3c/webcodecs/issues/508#issuecomment-1248720618> a > Mozilla position. At the same time, this seems small enough to not warrant > an explicit issue. (and it's good to have consensus on the issue) > That's a bit surprising. I think that's a pretty strong signal, but defer to the API owners. > > >> >> *WebKit*: No signal >> >> *Web developers*: No signals >> >> *Other signals*: Microsoft co-editor supports removal. >> >> 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? >> >> >> No. >> >> >> >> Debuggability >> >> n/a >> >> >> Will this feature be supported on all six Blink platforms (Windows, Mac, >> Linux, Chrome OS, Android, and Android WebView)?Yes >> >> Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >> ?Yes >> >> Flag namen/a >> >> Requires code in //chrome?False >> >> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1340190 >> >> Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1340190 >> >> Estimated milestones >> >> M108 >> >> >> Anticipated spec changes >> >> Open questions about a feature may be a source of future web compat or >> interop issues. Please list open issues (e.g. links to known github issues >> in the project for the feature specification) whose resolution may >> introduce web compat/interop risk (e.g., changing to naming or structure of >> the API in a non-backward-compatible way). >> https://github.com/w3c/webcodecs/pull/562 >> >> Link to entry on the Chrome Platform Status >> https://chromestatus.com/feature/4560781148946432 >> >> This intent message was generated by Chrome Platform Status >> <https://chromestatus.com/>. >> >> -- >> 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/CAPUDrwc%3D7%2B2KC73kKTUdWUmvQNubFtZGphhh8DXgQXnr%2BJc_LQ%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPUDrwc%3D7%2B2KC73kKTUdWUmvQNubFtZGphhh8DXgQXnr%2BJc_LQ%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/CAPUDrwcG4U84XgrePcCYdVR4ehYZirFdr8WNdF0vxX4Z9cbskw%40mail.gmail.com.
