Morphic breaks when colour dropdown shows

I don't know if this is something wrong with my system, but this happens when I try to use a colour dropdown:
Screen Recording 2023-11-02 at 6.32.37 PM

woahh, that's weird. it doesn't happen for me though.

I think you'll need to try the old turning on and off trick.

seems to be related to the latest Chrome version on the latest MacOS, and doesn't happen in other browsers. There have been multiple reports about browser graphics glitches in the latest MacOS, this is basically beyond our influence, let's hope Apple and Google are going to fix these glitches quickly. In the meantime you can always refresh the screen and again see everything by resizing the browser / Chrome window. That'll restore the display.

well I am using Chrome on Mac so I guess that explains it.

it's not just chrome on mac, i'm on windows 11 microsoft edge, and when i tried to use the set background color in the stage on snap 10.0 dev, this happened

microsoft edge is chromium based
also, dont use snap 10 for any projects. anything can change and break your project

Edge.119 @ Win10 the same problem for Snap v9, v10.
Works with GPU disabled.

Also works for me...

function newCanvas@morphic.js
...
 canvas.getContext("2d", {  willReadFrequently: true});

yes, I've been experimenting with turning on the willReadFrequently flag for all / most canvasses. Last time I did this, however, the overall slowdown to Snap! because of this was dramatic. I'll try again...
But ... setting the flag also doesn't solve the problem on my Mac...

For me the problem was caused by multiple consecutive, at every mouse move, call to
blocks.js

ColorSlotMorph.prototype.getUserColor = function () {
...
 hand.processMouseMove = function (event) {
   var clr = world.getGlobalPixelColor(hand.position());

I've tried
morphic.js

WorldMorph.prototype.getGlobalPixelColor = function (point) {
var dta = this.worldCanvas.getContext('2d', { willReadFrequently: true})

but it does not work. It seems that the GPU mode for the canvas is set at the first ever call to getContext.

The minimum required change for my system was

WorldMorph.prototype.init = function (aCanvas, fillPage) {
...
    this.worldCanvas = aCanvas;
    this.worldCanvas.getContext('2d', { willReadFrequently: true});

yes, I've tried the same over the weekend, i.e. setting the willReadFrequently flag when first initializing the World. But this leads to all kinds of other clipping glitches on my system, in which the wrong regions of the canvas get redrawn when applying clippings. I'm convinced that Google have - once again, as they've done so often in the past - broken some critical parts of Canvas.

Maybe disabling the "hardware acceleration", by the browser UI, will allow to survive until the next Chrome/Edge version...

Or picking the pixel color @ click to limit the call rate. It's not clear if getContext or getImageData has more detrimental effect. Maybe caching context will help.

Update: Chrome v.119 just arrived @Win10 with the same glitch.

I just wanted to put this out there, this also seems to happen on android. Whenever I tap on a color input, then tap anywhere else (lift up my finger), things become white with a small rectangle area that wasn't effected.

I tested this in
Browser: Brave 1.60.110, Chromium 119.0.6045.105
OS: android 14
Device: google pixel 6a

I’ve just published a patch (v9.0.11) which addresses this and related issues. Please let us know if you or your students still encounter color-sensing related glitches in Snap!.

Edge.119, Chrome.119 @ Win 10 :+1:

thank you for the quick test and confirmation!

For a couple of days I've explored various strategies to embrace the "willReadFrequently" canvas flag they want us to use, but ran into various clipping and performance issues down the road. So, for now I'm staying with the hardware-optimized version of Canvas, since we only need to read back the pixel data in mostly human-time (as opposed to computer time), and therefore it doesn't matter so much if those operations take a tad longer, whereas slowing down the actual rendering of images in compute-time is very noticeable for users. We'll see where this eventually leads to. Thanks for your input and for your suggestions!