LGTM1 It seems unlikely that even the (few) developers who access this data are somehow relying on it.
On Tue, Sep 20, 2022 at 8:10 PM Dale Curtis <[email protected]> wrote: > On Tue, Sep 20, 2022 at 3:36 AM Yoav Weiss <[email protected]> wrote: > >> >> >> On Fri, Sep 16, 2022 at 11:19 PM Dale Curtis <[email protected]> >> wrote: >> >>> Contact [email protected] >>> >>> 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. > That's a strong signal from the person editing the spec, but not an official Mozilla position. > > >> >> >>> >>> *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 bug >>> https://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 [email protected]. >>> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVQSA6gRu8eVfRyu8TPwXQhqduSVDZemsX0%3DGV4nY2jfg%40mail.gmail.com.
