I can't screenshot this, as the repaint caused by the screenshotting functionality removes the lines. ^_^

Adding fserb@ to triage.  However, the image doesn't load at all when I try the page.  tabatkins@ could you check if it is still working?

The demo works for me on Mac OS in today’s Canary and stable.

Canary: 72.0.3592.0 (Official Build) canary (64-bit)
3274d2b27158c8f54008ac69629235202f28f306-refs/branch-heads/3592@{#1}

To repro this, you probably need --enable-experimental-web-platform-features, as the demo requires script module support.

I honestly can't see what I'm supposed to see on the broken case. Maybe if you make this artificially slower?

Dunno why I didn't think about just recording a video on my phone. 😀 Attached is a video showing the blend lines appearing and gradually disappearing as it draws, then some persisting when the drawing is finished, until I scroll and they finally all disappear.

And yes, it needs the flag, sorry about forgetting to mention that.

Ugh, video didn't upload right. I'll keep trying, one sec.

Okay, so https://photos.app.goo.gl/kZ5Qtm1bue763yMZ8 should work if you just hover it and watch the preview; for some reason it errors out on my computer if I click and watch the video itself.

Thanks for the video!
Yeah, I was def not seeing this on my machine.

Adding Compositing and Paint that may have a better idea of what's wrong here.

I can reproduce on Mac Canary 72.0.3596.0, Retina display. Also reproduces on Windows 10 at 125% screen resolution.

I don't know enough about how this operates to make a call. From Blink's perspective we're just painting a canvas, so the issue is not cracks in layout or painting. That leaves the data being placed into the buffer, presumably. Maybe we round oddly and skip subpixels, which would explain it being easy to reproduce on a Retina display or with a zoom-for-dsf implementation.

It could even be an site error, though I don't recall the rules for accessing sub-pixel sizes etc.

It being subpixel related is likely; the lines are *hairline* and probably too thin to be full-pixel errors.

It's definitely not a site error. I'm not accessing a high-res canvas, I'm just calling putImageData() with 8x8 pixel ImageData blocks, placed in 8-pixels rows and columns, as you can see in the worker code at <view-source:https://www.xanthir.com/etc/jpg/worker.js>  I'm also just iterating thru the canvas once, touching each pixel exactly one time, so there's no way the code could be causing the hairlines to go away after a while (not to mention the "everything goes away and looks correct after a scroll" issue).

What I'm *guessing* is occurring is that it's a combination of:

1. the compositor doing subpixel blending, so the edges of the patches are slightly lightened by the surrounding white
2. the compositor being smart and only invalidating the exact pixels being written to by putImageData(), so the lightened pixels on the previous row aren't repainted (and properly blended with the new pixel data) when the next row starts getting painted

Why this only manifest as horizontal lines and not vertical, I'm not sure. Maybe it internally pushes commits when bounding dirtied area exceeds a certain size, that happens to be between one and two rows of pixels blocks? Maybe it's just a weird internal detail of how it does subpixel blending?

Whatever it is, tho, it's both undesirable *and* a clear behavior difference from main-thread canvas.

I wonder if this is an accelerated vs unaccelerated canvas difference? (Does offscreen canvas make different selections on that heuristic?)

The 125% screen resolution comment makes this smell like a floating point issue in canvas code or in Skia.  I wonder if AA is being applied when it shouldn't be?

My understand of offscreen canvas here is that it doesn't do anything differently with respect to compositing.  The canvas code ends up generating the same gpu commands but just delivers the final texture to the display compositor along a different path when it's offscreen.

enne, you are correct about the offscreencanvas canvas.
But if this was a Canvas or Skia issue, it wouldn't get solved without a redraw of the canvas, right? If it disappears on scrolling, it means the canvas buffer is correct, no?

Is there a way to disable partial raster? The behavior differs when incrementally updating from the decode, vs drawing all at once on repaint.

So it's either partial raster or maybe paint invalidation.

It could be a Skia issue if we're issuing a clip that's incorrect or Skia rasters differently when given a clip that's not the entire canvas?  I wasn't aware that canvas code did partial raster, but if it does, then I've seen similar bugs in the past.

I'm still not sure why it could be that. This is still happening after the final raster is done, in the end of the video, no? The canvas is fully draw, the lines are there, and they disappear when it scrolls.

Correct. Some of the early lines disappear partway thru painting, but later ones stick around after it's fully drawn, until a scroll.