On Tue, Nov 15, 2022 at 3:18 PM 'Christopher Cameron' via blink-dev < blink-dev@chromium.org> wrote:
> On Tue, Nov 15, 2022 at 7:23 PM Mike Taylor <miketa...@chromium.org> > wrote: > >> On 11/15/22 11:21 AM, 'Christopher Cameron' via blink-dev wrote: >> >> *Contact email:* >> ccame...@chromium.org >> >> *Explainer:* None >> *Specification:* None >> >> *Summary:* >> These fields were accidentally exposed to the web in crrev.com/562990 by >> way of crrev.com/427153. They are not part of any specification. >> >> These CLs landed in 2018 and 2016... do we have any UseCounter or usage >> data? >> > > We don't have usage counters for these members of ImageEncodeOptions. > > We do have stats for the relevant APIs though. The proposal (removing the > parameters) will bring OffscreenCanvasConvertToBlob in line with the > related CanvasToBlob and CanvasToDataURL, both of which are far more > popular. > > - OffscreenCanvasConvertToBlob > > <https://chromestatus.com/metrics/feature/popularity#OffscreenCanvasConvertToBlob> > is used by 0.0284% pageloads > > That's helpful as an upper bar to impact. > > - CanvasToBlob > <https://chromestatus.com/metrics/feature/popularity#CanvasToBlob> > which is used by 0.1337% (leet?) of pageloads > - CanvasToDataURL > <https://chromestatus.com/metrics/feature/popularity#CanvasToDataURL> which > is used by 19.1624% (wow!) of pageloads > > Of note is that: > > - There is no documentation of colorSpace and pixelFormat -- the only > way to know they exist is to read our IDL files > > That and lack of support in any other engine certainly suggests this is likely to be just a bug fix that nobody notices. But it's always scary to do this blind - the web is weird. > > - The only effect that those ImageEncodeOptions can have is to degrade > the quality of the resulting image > > If that's really true, then I'd be supportive of removing it without further data. But I don't understand why it wouldn't be possible for eg. some image blob processing code to be written assuming uint8 pixels and then break horribly in scenarios where it starts getting uint16 pixels. Am I missing something? If we're not 100% confident in the safety of removal then I'd suggest landing a simple UseCounter now, and removing in the next milestone. You could probably even get the UseCounter merged into M109 if you want, then land removal for M110 now. But I'm open to an argument that this is definitely unnecessary extra work. > -- > 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/CAGnfxj-1rrD9R2nwoqpSvN2gwONZ9_LdYFhz4TyjT5695wBx2Q%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGnfxj-1rrD9R2nwoqpSvN2gwONZ9_LdYFhz4TyjT5695wBx2Q%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/CAFUtAY-RgrWmDmV99v-QebMpZFiZ%2BzXmVRrQ%2BE_X%3DzU%3DroNgBg%40mail.gmail.com.
