Canvases should reset their contents when width or height is set #3613
Conversation
even if the sizes are the same. Note: Canvas 2D does this. There are various issues related to requestAnimationFrame and ResizeObserver that this affects. It would probably be best of all the APIs did the same thing so that the workarounds for resizing the canvas are the same across APIs Safari passes this test, Firefox and Chrome fail
|
Probably need a similar test for OffscreenCanvas? |
| gl.clearColor(0.25, 0.5, 0.75, 1); | ||
| gl.clear(gl.COLOR_BUFFER_BIT | gl.DEPTH_BUFFER_BIT); | ||
| // Check it's not cleared | ||
| checkCanvasContentIs(64, 128, 192, 255); |
There was a problem hiding this comment.
Would be nice to test that stencil and depth are cleared, too. That's of course cumbersome..
FYI, Offscreen canvas is apparently different. Safari, Firefox, and Chrome don't reset the WebGL canvas when the size is set to the same size. |
|
I believe we have a different test that requires the opposite, or otherwise that there is content that assumes the opposite, because I see this line in Firefox: |
|
Safari doesn't do this so any site that is expecting a no-op is not getting a no-op |
|
What is the purpose of resetting the contents when width or height is set to the same size? I'm pretty sure this kind of choice is behind most of the cases where I see the content I want to read then the screen/window/canvas goes black and the same content is redrawn usually after an irritatingly long time. This is ugly and annoying to the user. |
|
It is already true and expected in Canvas 2D. It can't be fixed there because people actually use it as a shortcut to clear the canvas. The interop between compositing the page and canvas updates has a bunch of issues. See: https://stackoverflow.com/questions/77842752/how-do-i-use-resizeobserver-with-requestanimationframe-correctly. Because of that, IMO, it would best of all the canvas APIs did the same thing here so that the correct usage for one type of context ("2d", "webgl", "webgl2", "webgpu", "bitmaprender") is the same for all types of contexts. Otherwise you get into this issue where you do things one way, they seem to work, you pass on that "this is how you use canvas" message on the internet. You post examples. People copy the examples. It spreads far and wide. But, it turns out it's wrong because different canvas APIs treat this differently. If they all treat it the same then the "this is how you use canvas" issue has one correct answer. Further, anyone who was expecting it to be a no-op was wrong. It's never been a no-op on Safari so all iOS users and all MacOS users using Safari, this has never been a no-op |
|
I do not think there is enough benefit here to outweigh the backwards-compat hit. |
|
What backward compat hit? It already clears on Safari so you wanted to be compatible for the last 11 years you needed to deal with the fact that it clears. |
|
When I accidentally made this change in Firefox ~5years ago, I reverted it for a reason. I regret that I did not write down what it was. |
|
Per WebGL working group meeting of 2024-02-08: to make progress on this, it's necessary to create a patch (perhaps against Chromium) which removes the early-out for resizing canvases to the same size, and send that patch through the trybots, which will run the entire WebGL CTS. This will help find whether there is a test which contradicts the one being added here. |
even if the sizes are the same.
Note: Canvas 2D does this. There are various issues related to requestAnimationFrame and ResizeObserver that this affects. It would probably be best of all the APIs did the same thing so that the workarounds for resizing the canvas are the same across APIs
Safari passes this test, Firefox and Chrome fail