Border radius produces unstable rendering in headless Chrome on Linux |
||||||
Issue descriptionChrome Version: 72.0.3618.0 (r609904) OS: Linux (Debian and CentOS) What steps will reproduce the problem? (1) Load a page with border-radius. (2) Save a screenshot. (3) Do it repeatedly and diff them together. A test case and repro notes are available in this git repo: https://github.com/happo/chrome-spurious-repro Specifically the minimal html is here: https://github.com/happo/chrome-spurious-repro/blob/2e7d748adebc472e0b1b975ec5a4c869fee23f18/repro.js#L12 <style> main { border-radius: 3px; height: 20px; width: 20px; border:1px solid rgba(20,171,142,0.3); } </style> <main></main> What is the expected result? Rendering should always be the same. Other tested browsers (Edge, IE11, Firefox, Safari, iOS Safari) all produce identical rendering every time. What happens instead? Rendering appears unstable, the corners are sometimes a slightly different color. Looking at Digital Color Meter it looks like an off by one in the color channels so maybe rounding somewhere in Skia or CC? It's not visibly different to the human eye, but any machine diffing tool thinks the screenshots are different. Note: - This doesn't appear to repro on OS X. - The --disable-gpu flag doesn't fix it.
,
Jan 8
,
Jan 8
Thanks @esprehn for helping me file this issue. I thought I'll add a little more context here. First of all, this issue is only reproducible if the same element is rendered multiple times within the same page. If I force a fresh page load in between renderings, the screenshot is always the same (65bfa89f8fd2c5206c249c5953a319f8.png in the repro-repo https://github.com/happo/chrome-spurious-repro). This seems to be linux-only. I've seen it in Debian and Centos7. I've never seen it in Mac OSx.
,
Jan 8
Interesting, looks like the first couple of frames/snapshots are rendered differently, then it stabilizes: 65bfa89f8fd2c5206c249c5953a319f8.png 65bfa89f8fd2c5206c249c5953a319f8.png eae8fa65c444be73981b0bbd838d73c2.png eae8fa65c444be73981b0bbd838d73c2.png eae8fa65c444be73981b0bbd838d73c2.png eae8fa65c444be73981b0bbd838d73c2.png eae8fa65c444be73981b0bbd838d73c2.png ... In a local browser, I'm only seeing the first hash (65bfa89f8fd2c5206c249c5953a319f8). This is hitting the software Skia backend. As esprehn@ mentioned, the red channel appears to be off by one in the rounded corner AA region. +mtklein, can you think of anything that would trigger this sort of instability in Skia? (I'm not ruling out external factors at this point) Looks like a trivial drawRRect() call, see attached SKP. (would be nice to have repro instructions with a local chrome-headless build)
,
Jan 8
Do you know if this reproduces in regular chrome (i.e., when loading the page and taking a screenshot), or is it only via headless? I attempted to reproduce without headless on linux and was not able to. Do you have a guess about why this doesn't reproduce in our web/layout tests?
,
Jan 8
I cannot repro in regular chrome either, always getting the same rendering (equivalent to 65bfa89f8fd2c5206c249c5953a319f8.png). Then again, I'm not sure what puppeteer/takeScreenshot does under the hood (does it force a re-rasterization? or just reads back some buffer?). I'm not surprised that layout tests are stable - we expect a deterministic rendering for stable inputs (Skia's test suite would also explode otherwise). Also the variation appears to be related to the number of takeScreenshot invocations, which would not be a factor in layout tests.
,
Jan 9
Interesting! On my (Mac) laptop I'm reliably getting the same content as the other one, eae8fa65c444be73981b0bbd838d73c2.png, DM checksum 82b5f6a226ec63cda64343045e20ab3b with --config 8888. Here's how I'm repro'ing, fwiw
DEF_SIMPLE_GM(rrect_919955, c, 22, 22) {
SkPaint p;
p.setAntiAlias(true);
p.setColor(SkColorSetARGB(77, 20, 171, 142));
p.setStyle(SkPaint::kStroke_Style);
p.setStrokeWidth(1.0f);
c->drawRRect(SkRRect::MakeRectXY({0.5f,0.5f, 21.5f,21.5f}, 2.5f, 2.5f), p);
}
,
Jan 9
(Also getting the same results from the .skp you helpfully uploaded... duh.)
,
Jan 9
Oh, let me step that back. Was doing the diff wrong... back to not sure about the .skp.
,
Jan 9
@fmalita, in your reproduction in comment #4, are the skps the same between runs or different?
,
Jan 9
The SKPs I was able to capture appear to be the same. I just figured out how to swap a local chromium build into the repro, so I should be able to narrow down some more now.
,
Jan 9
,
Jan 9
Narrowed down to a Skia issue: the hairline rasterizer is sensitive to drawing next to (but fully inside) the clip edge (see linked Skia bug). The variation only shows after a couple of snapshots because of CC partial rasterization: first couple of times the tile is rasterized with an open clip, then partial raster kicks in and the tile is re-rasterized with a tight inval clip (then the rrect is clip-edge-adjacent).
,
Jan 9
Do we use partial rasterization in layout tests? Could this reduce flakiness?
,
Jan 9
I assume we do use partial raster for layout tests (enne?), but I'm also guessing the trigger conditions are deterministic - so I wouldn't expect to flip-flop in between test runs. Have you noticed flakes with subtle AA diffs? I don't recall seeing any, but it would be awesome if fixing this would help reduce flakiness!
,
Jan 9
We don't turn off partial raster for layout tests. I think I would expect software raster partial raster to be a little bit more deterministic (because it's reusing local scratch buffers vs returned resources), but any change in invalidation patterns will cause this to get reordered. I have definitely seen Skia issues in the past where rastering near clips has caused issues. I think the right thing to do is to fix Skia to be consistent. I haven't seen any flakes with subtle AA diffs. Plenty of AA diffs in general, but not flaky ones.
,
Jan 9
For anyone looking for a workaround to this issue, adding the `--disable-partial-raster` flag removes the screenshot flakiness. @see https://github.com/happo/chrome-spurious-repro/commit/1789ec159aabb96e9fe6eecd41603c258640f0bc |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by esprehn@chromium.org
, Jan 8