Black and white dots appearing on stage on Chromebook

[fsih]

Several users are reporting seeing black dots on stage.
I'm seeing this issue on Samsung Chromebook 3, Chrome version 76. Was NOT seeing it on Chrome version 75.
Not able to repro on Mac 10.14, Chrome 76
Not able to repro on Windows 10, Chrome 76

The issue is visible at all stage scales, whether in the editor or on the project page. The dots are not visible in the paint editor. The dots appear regardless of the color of the costume or whether the costume is bitmap or vector. Dots change location when the sprite is dragged to a different place on the stage.

[fsih]

A couple of user threads
https://scratch.mit.edu/discuss/topic/367470/
https://scratch.mit.edu/discuss/topic/367460/

[fsih]

Filed https://bugs.chromium.org/p/chromium/issues/detail?id=996323 on Chrome

[fsih]

Some comments from @paulkaplan
a couple other observations: it isn’t in the paint editor, meaning it isn’t a 2d canvas problem. It also isn’t in the image you get when you drag the cat around on the stage, which is kinda wild because that is pixels retrieved from the renderer itself. It is present on the thumbnail (which makes sense, that is just the canvas converted to pixels)

[fsih]

https://bugs.chromium.org/p/chromium/issues/detail?id=996323#c2 Chrome responded on the bug and wants a minimum repro. @cwillisf any chance there is a very stripped-down version of the renderer that I could start from?

[adroitwhiz]

Does the issue appear in the "playground"?

[paulkaplan]

@adroitwhiz it does, yeah. @fsih you might be able to start from the playground, that would at least take out everything other than the renderer. (llk.github.io/scratch-render)

[fsih]

I am working on squeezing the water out of a rock here: https://github.com/fsih/scratch-render/tree/gh2/src

[fsih]

The Chrome team gave us a work-around, change the line
return twgl.getWebGLContext(canvas, {alpha: false, stencil: true});
to
return twgl.getWebGLContext(canvas, {alpha: false, stencil: true , antialias: false});

@cwillisf @mzgoddard thoughts on if this would be a safe fix to implement, or if we would rather wait for the Chrome fix?

[adroitwhiz]

@fsih Disabling antialiasing will make pixels along the bounding-box edges of vector sprites appear jagged.

This should not break anything, as some devices do not support antialiasing anyway. Note that on those devices, the same "jaggies" behavior will occur. In my opinion, it would be best to disable antialiasing for consistency's sake anyway.

In the longer term, it would be possible to render SVGs with a pixel of padding around them and avoid the jaggies problem-- I could probably implement this easily in my experimental branch which fixes bounding-box jitter [#427].

[fsih]

@adroitwhiz that's a good point about consistency. In that case, I'll turn off antialiasing, and we can test how that feels.

By the way, we really appreciate all the PRs you've been writing. We're backlogged right now, but we should have a chance to review them soon!