jmoenig / Snap

a visual programming language inspired by Scratch
http://snap.berkeley.edu
GNU Affero General Public License v3.0
1.49k stars 742 forks source link

Rendering Issues in Chrome 71 #2217

Closed jmoenig closed 5 years ago

jmoenig commented 5 years ago

This is a potential show-stopper issue coming up in a few weeks, when Chrome Canary 71 hits the main Chrome distribution channel: Under certain conditions, apparently just nesting blocks, block labels sometimes stop rendering, and it appears if though the label is lost, when, in fact, it's not.

I've opened an issue with Google Chrome: https://productforums.google.com/forum/#!topic/chrome/Uv9WDd3Er0k;context-place=forum/chrome

jmoenig commented 5 years ago

So, after tons of experimenting and searching, tweaking Morphic etc. I've discovered that if I disable our "retina support" - not in the menu after Snap has loaded, but right in the Morphic source code - everything works great, and there are no artefacts. Also Snap looks kinda sucky on my MBP. But hey, it's astounding how goddam fast and snappy Snap has become without retina support. Geez! Now, let's dive into retina support. I've always hated it, it's the root of so many issues and such performance lags...

jmoenig commented 5 years ago

Okay, strike that. Even in non-retina support these problems occur, but they are not as easily reproducible. It just took me longer to make then happen. Did I ever mention how much I hate browsers? And Google?

jmoenig commented 5 years ago

Hey, if it's happening quicker in retina mode and only after a while in non-retina, it might be a resource issue. Maybe Chrome is running out of texture memory. Geez.

jmoenig commented 5 years ago

Documenting this some more: When I disabler "hardware acceleration" in the advanced settings menu, everything seems to once again work fine without any loss, both in retina- and non-retina support modes.

Testing this some more with longer edits...

jmoenig commented 5 years ago

So, I can confirm that disabling the Chrome setting "hardware acceleration" solves the issue:

hardware_acceleration

By default, this setting is enabled in Chrome Canary 71, the same as it is enabled by default in current Chrome stable 69.

Bummer. So, we do have a work-around of sorts, but nothing that we can automatically do on our side to help kids in school.

Let's bring this up with Google!

jmoenig commented 5 years ago

Hmm... of course, turning off hardware acceleration also dramatically slows down many Snap! projects. Sigh. Did I mention I hate browsers?

brianharvey commented 5 years ago

Damn, I was hoping you'd have to turn off Retina support. :-/

Don't forget to update your Chrome bug report.

jmoenig commented 5 years ago

I did update the bug-report. Actually, I did update the report in the Chrome forum, the original bug report went to an undisclosed recipient and doesn't seem to be trackable.

jmoenig commented 5 years ago

hmm... I write a bug-report directly using the Chrome-report-an-issue menu, and I also posted the bug report in the Chrome dev forums. No reaction yet from anyone at Google. I'm starting to panic...

jmoenig commented 5 years ago

anybody know anyone at Google whom we can alert this issue to?

towerofnix commented 5 years ago

@jmoenig no, unfortunately. You might be able to find someone who's worked on similar graphics/memory/etc bugs in the issue tracker? (You could also ask on the Snap! scratch forum thread - there might be people following the topic who'll know someone.)

jmoenig commented 5 years ago

In today's Canary nightly build 71.0.3571.0 the issue is no longer reproducible and seems to be resolved now. Phew. that was close! :-)

I'm still very puzzled where to report Chrome issues to...