I see this in the checked-in baseline, but I cannot repro in Chromium proper.  Am I missing some flags, or any idea why content_shell/DRT might behave differently?

Does the test fail in your environment?

No, the test "passes" (the result matches the checked in image with #fefefe bleed).

But if I open the test in chromium, as opposed to running the layout test, the bleed is not present.

What if you open it in content_shell?

Standalone content_shell also shows the bleed.  But it's limiting for debugging (don't know how to grab an SKP for example), and makes me wonder whether the problem is with content_shell rather than inval/raster in general.

Oh, I can repro in chrome with --enable-partial-raster.

Looking closer at the rightmost pixels (the ones near the window edge), I'm starting to think this is not an inval bounds vs raster bounds issue:

 - the right edge has a significant red component in frame 0, but is almost white (#fefefe) in frame 1
 - if this was an under-invalidation issue, I expect we would have bled the whole rightmost pixel column;  instead, we're clearly redrawing it in frame 1 => so we're not really drawing outside the inval rect.

Wild guess: this is some weird blend quirk (white-on-white with an unaligned partial raster clip rect).

I vaguely remember mtklein@ mentioned we allow ourselves to be off-by-one when for certain blending cases in software mode?

But I'm not sure why the partial raster clip would ever be unaligned to trigger coverage-based blending.

Still looking.

Deleted: frame0.png 1.4 KB

	frame0.png 1.4 KB View Download

Deleted: frame1.png 1.1 KB

	frame1.png 1.1 KB View Download

Yeah, I wouldn't say so much "allow" as "are resigned to".  The legacy software backend is filled with arbitrary speed hacks and bugs, either of which could cause blends to go off by 1.

OK, that would explain the issue iff there's an unaligned partial-raster clip.  ericrk@ do you know what could cause that?  Maybe the 90deg rotation?

A couple more things I found:

1) this renders with the same artifacts as the test (drop-in rotated-subpixel-expected.html, passes):

<div id="target" style="
  position: absolute;
  top: 100.6px;
  right: 0;
  height: 100px;
  width: 100.6px;
  transform: rotate(90deg);
  transform-origin: 100% 0;
  background-color: white">
</div>


2) if I remove the transform from the above, the artifacts go away - which is kind of surprising;  I tracked it down to

  * std::cos(90) is not exactly 0.0 (== 6.12303e-17)
  * that introduces a residual non-zero scaleX component on the matrix
  * which in turn causes SkMatrix::rectStaysRect() to return false
  * which makes Skia take a more complex code path for drawing the rect (drawPath instead of drawRect)
  * which likely affects the blitter choice and introduces the discrepancy

My conclusion, based on #1, is that this is not really an inval-vs-raster problem (we're not drawing outside the computed geometry; there is no inval/repaint in repro above), but just an occurrence of the blitter issue mentioned by mtklein (components are off-by-one for some legacy blitters).

Also, while the partial-raster trigger is interesting (not sure why it makes a difference), I don't believe it's directly related to the artifacts.

AFAIK we don't have plans to address all the legacy blitter corner cases in Skia.  Feel free to reopen if you think there's more to this.