On Wed, Nov 16, 2022, 7:30 PM Rick Byers <rby...@chromium.org> wrote:
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 <http://crrev.com/562990> by way of
crrev.com/427153 <http://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
I see - thanks.
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?
I also have this question, for pixelFormat.
As a workaround to specify the color-space (except for display-p3?), do
I understand correctly that that sites could do something like like the
following, e.g.,
f = new OffscreenCanvas(10,10);
f.getContext("2d", {colorSpace: "srgb"}) //or "display-p3", but not rec2020?
f.convertToBlob().then(b => doSomething(b))
Give your previous answer, the side effect for this is the image might
look different (worse? degraded?), I think.
If that's true, it seems safer to remove colorSpace than pixelFormat. If
there is some risk to removing pixelFormat, a UseCounter seems prudent
(or at least some HTTPArchive analysis to see how people are processing
blobs where it's used).
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/79d4cb7e-d5ea-3c70-454c-6dfa2ce681f3%40chromium.org.
