Screen Refresh erases costume data

With the latest Chrome update ( Version 98.0.4758.82 (Official Build) (64-bit)), a bug got introduced , where if one changes tabs and returns to SNAP, the window content is not visible. Then when the window edges are moved to resize by about 5mm or so, the content restores. However, all the sprite costume data erases even though the names are listed.

The same problem happened with the MicroBlocks IDE, but John fixed it yesterday.
This is probably not a Snap bug per se, but introduced by the new browser update.

Same here. And minimizing and then restoring does the same thing. Windows 10.

Edge doesn't seem to have this problem even though similar version:
Version 98.0.1108.50 (Official build) (64-bit)

This looks very similar to this: canvas - Chrome - returning to my webpage, tab goes blank - Stack Overflow However Snap! does use requestAnimationFrame

hmm... doesn't (yet) appear on my Mac in the current version, which seems to be slightly behind the Windows one - 98.0.4758.80 - but also not in Chrome Canary, which is ahead - 100.0.4886.0 - I hate it when Google breaks Chrome, what happens at least once every year, usually in the Fall, though.

Seems to work fine in Canary, so I'll use that (assuming it doesn't have other problems)

I've just pushed a quick temporary fix to dev. Could anyone with a Windows 10 PC do a quick test and compare the currently deployed Snap! version against the current dev version (make sure to do a "hard reload" please), and let me know whether the quick fix actually addresses this issue? Thanks!

Still the same in my machine.
image image

Slightly better - IDE is refreshed but costumes and stage still broken.

Same for me. All costumes become black.

thanks, folks. I'm having the problem that I can't reproduce the issue at all. I've just checked my son's Windows 10 PC with the latest Chrome version 98.0.4758.82 (Official Build) (64-bit) and even the regular Snap installation (the one without any fix) works absolutely flawlessly, no blank tabs, no lost costume data either, no matter what I try (switching to another tab, minimizing the Snap tab etc.). Can you show me how to reproduce this? Thanks!

Chromium bug details and reproduction
# Issue 1294863: Images drawn using canvas.drawImage method disappear after switching tabs

thanks, Dariusz. I still can't reproduce this on my son's PC with that very Chrome version. But let me try one more idea for a quick fix...

Did you notice...

Some combinations:

  • Running under xorg works as expected.
  • If I disable "Accelerated 2D canvas" (which is enabled by default), leaving "Experimental Web Platform features"" enabled works as expected (wayland)
  • if I just disable "Experimental Web Platform features" works as expected (wayland)

BTW: it seems to be relased too early but planned in long run
https://chromestatus.com/feature/5678204184428544

Yup. 7.1.4 works fine after disabling the following in chrome://flags

Accelerated 2D canvas

Enables the use of the GPU to perform 2d canvas rendering instead of using software rendering. – Mac, Windows, Linux, Chrome OS, Android, Fuchsia

#disable-accelerated-2d-canvas

Aside from Google's terrible kludging around with the Canvas API over the past years ... Can you try again with the little change I've just pushed to the dev version (again making sure to "hard" reload it once? It rerenders every visible morph when the page gets focus. This is kinda overkill, but maybe it works. Thanks!

Costumes still disappear in that version.

"Turtle" is recreated with slight, clearly perceived, delay but ad'hoc painted costumes do not.

beats me, then. Costume data is stored (only) in a canvas element. if that gets invalidated there's nothing I can do...

Is there a way to warn people and suggest they turn off accelerated 2d canvas? You should be able to test if a canvas becomes empty when the page gets focus so the warning would only be seen by those suffering from this.

none that I know of. Sigh. let's just hope that Google is going to push the next version real soon, because that apparently fixes it again.

hmm... maybe we could switch to OffsceenCanvas for Costumes. We've tried switching everything to OffsceenCanvas before, and that was actually really promising, but it's not yet widely supported by different browsers, and if there's one thing I refuse to maintain it's polyfills (because they're totally defeating the purpose of standards). Lemme try some more things, then....

Okay, whoever is still online in this thread: Could you help me out with one more test, whether the latest quick idea in the dev version (after doing another hard reload) addresses the lost-costumes phenomenon?

(this is a pretty drastic quick change which also breaks many other things, I'm just interested whether this is a direction to potentially follow up upon). Thanks!