Assigning to Florin as most expert in this area. But feel free to re-assign.

Initial findings -

1) only occurs in HiDPI mode (presumably the reporter uses a Retina display); use --force-device-scale-factor=2 to repro; the repro is somewhat dependent on window size/positioning - resize to trigger (or use a higher DSF, like 4)

2) seems related to the computed clip rrect geometry in Blink; we're stroking a border-rrect centered 1px border, then insetting by 0.5 for the clip => the clip rrect is supposed to be 1px smaller in both dimension, with radii adjusted accordingly.

In regular DPI mode, the rrects look as expected:

  border: [0.5 0.5 601.5 387.5] / 19.5r  => size: 601x387
  clip:   [1   1   601   387  ] / 19r    => size: 600x386

In HiDPI mode:

  border: [0.5 0.5 601.5 385.5] / 19.5r  => size: 601x385
  clip:   [1   1   601   386  ] / 19r    => size: 600x385

Something's off with the height numbers in HiDPI mode - while we're shrinking the width/radii as expected, we're not doing the same for height => the clip rrect bottom arcs are not concentric vs. the border arcs.

Looking.

Deleted: dsf6-repro.png 1.6 KB

	dsf6-repro.png 1.6 KB View Download

I tracked this down to border rect subpixel discrepancies between the regular layer paint path and the layer descendant clip path.

When painting the border, we call ComputedStyle::getRoundedInnerBorderFor() with a borderRect.y == -0.5. This comes from the layer location, which is taken into account during content paint: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/paint/PaintLayerPainter.cpp&l=695

OTOH, when clipping layer descendants, we pass a borderRect.y == 0 to getRoundedInnerBorderFor().  This comes from the layer pagination offset, which is the only offset used for LayerClipRecorder from PaintLayerPainter::paintForegroundForFragments(): https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/paint/PaintLayerPainter.cpp&l=735


So

1) paintFragmentWithPhase uses an offset based on the layer location (which happens to have a subpixel phase, y == -0.5)
2) paintForegroundForFragments uses a descendant clipping offset based on on the layer pagination offset (which in this case yields y == 0)
3) hence the border rects passed to getRoundedInnerBorderFor are pixel-snapped differently => the border and the descendant clip rounded-rects are misaligned.

I'm not sure which of the two code paths is correct.

Attaching a reduced test (open with --force-device-scale-factor=2 and resize vertically if the problem is not immediately obvious).

Chris, do you think this is something that will get fixed in SPv2?  Either way, please reassign to someone more familiar with layer clipping vs painting voodoo.

Deleted: reduced.html 650 bytes

reduced.html 650 bytes View Download

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The corners look decent now at almost any size, but the bottom border disappears at some sizes, no doubt due to sub-pixel border painting.