Replies: 4 comments
-
@jdashg do you think this could be related to Firefox's recent release of colorspace handling? There are several associated tests in the WebGL conformance suite, but I'm not sure whether this particular case is covered. |
Beta Was this translation helpful? Give feedback.
-
It's hard to say, but possibly! It would be great to have a testcase that's 50%gray which would make it easier to tell (or at least guess) who's getting what wrong. |
Beta Was this translation helpful? Give feedback.
-
Yup, a test case (testing the various presentation paths) would be really helpful. BTW, it should include a css |
Beta Was this translation helpful? Give feedback.
-
That's true, we can't guarantee a window-pixel result. However we do (should?) require consistency between elements in a page. 50% red should be the same coming from CSS or WebGL, though it may have different window tints across different browsers. |
Beta Was this translation helpful? Give feedback.
-
This looks like a browser bug, though I'm not sure who is right and who is wrong.
If we turn off OffscreenCanvas, then both Firefox and Chrome use the same codepaths (direct canvas rendering for a single instance, and drawImage transfers for multiple instances). In this case they are each self-consistent for single vs. multiple instances, but not with each other:
Chrome:
Firefox:
Note the red buttons: for Chrome we get RGB = [198, 58, 58], while Firefox we get RGB = [215, 40, 50]. This is on a macbook Pro, so some kind of colorspace is getting incorrectly applied in one or the other.
Stranger yet, with OffscreenCanvas enabled (Chrome only), for single instance direct draw, we now get the same value as Firefox had, while for multiple instance using transferImageBitmap, we still get the non-OffscreenCanvas Chrome value.
I'd love to have a test that would tell me definitively which one is correct, but I haven't thought of anything I would trust yet.
Beta Was this translation helpful? Give feedback.
All reactions