Clarify behavior of out-of-gamut canvas - #4476
Conversation
It's OK if out-of-gamut intermediate values are written to the canvas, it only matters what's there when it gets presented.
kainino0x
added
the
copyediting
|
@jimblandy revised, PTAL |
|
Previews, as seen when this build job started (fe175dc): |
| {{GPUCanvasAlphaMode/"premultiplied"}}, {{PredefinedColorSpace/"srgb"}}, | ||
| {{GPUTextureFormat/"rgba8unorm"}} canvas, the color `[0.51, 0, 0, 0.5]` represents | ||
| <code><a funcdef>color</a>(srgb 1.02 0 0 / 0.5)</code>, | ||
| however upon presentation it could be internally unpremultiplied before color |
There was a problem hiding this comment.
It's probably not actually likely that a browser would unpremultiply like this, as basically everything prefers to operate in premultiplied space. I don't think this is the only case under which bad things would happen. It was the easiest to explain, but could it mislead people to believe this is actually a likely scenario?
The example is not critical, but it's very helpful to demonstrate what we're talking about. Maybe it would be possible to show other examples as well of hypothetical compositing+display pipelines?
|
I thought about this further, and I think there are some cases that this doesn't allow that we need to allow. I'm going to tentatively close this and open a new PR that does that. |
Actually, we still need to fix this. I will still open another PR that both reduces the undefined behaviors and expands the examples. |
Opened draft #4526. |
|
(This PR is ready for review though. PTAL) |
|
The change makes sense to me. |
toji
left a comment
toji
left a comment
There was a problem hiding this comment.
LGTM, especially if @ccameron-chromium is comfortable with it.
3 participants
It's OK if out-of-gamut intermediate values are written to the canvas, it only matters what's there when it gets presented.
Also move the existing explanation of the undefined behavior to a note,
and expand it with an example.