New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 7 users
Status: New
Area: Clipping
Priority: Low
Type: Defect

Sign in to add a comment
Tile grid clipping problems
Project Member Reported by, Apr 3 2013 Back to list
In Chrome, we raster a stack of pictures from top to bottom and do a clip + SkRegion::kDifference_Op to clip out the portions from pictures above us that have already been drawn so that pictures beneath don't draw over top of them.

When we do this, sometimes portions of recorded content get clipped away incorrectly, leaving an unrastered portion of the canvas.  I believe this is an issue with tile grid incorrectly clipping some recorded operation that is needed for rasterizing, which is why I am filing this as a Skia bug.

See  for a screenshot.  The cyan fill color comes (in debug builds) from  We fill the entire canvas with that debug color, so if nothing rasters to that part of the canvas, then you will see that color.

If I raster the pictures in the other order, from bottom to top without any clips, then there is no unrastered portion of the canvas.  This makes me think that there is nothing missing in the recording.

If I turn tile grid off, this problem goes away.

I don't have a Skia-only repro for this as it depends on a certain set of clips and content.  However, this reproduces for me consistently if I build debug Chrome at ToT (r192074 right now) and run:

out/Debug/chrome --enable-impl-side-painting --enable-threaded-compositing --force-compositing-mode

...and then select text on the page for a minute until I see cyan.
Project Member Comment 1 by, Apr 3 2013
Project Member Comment 2 by, Apr 4 2013
I think I can reproduce this transiently (at r189024) by hilighting a chunk of text in the center column of the page. A cyan bar perhaps two pixels wide flashes to the left of the center column, and then usually disappears one frame later, although I've been able to make it stay around from time to time.

If I have composited render layer borders turned on, it's clear that what *usually* happens is that partially-hilighted tiles don't have any problem, but any tile which is completely spanned top to bottom by hilighting gets the bar alongside. (Or almost completely - the cyan bar appears when my cursor gets within 3-4 pixels of the tile border, apparently because I'm overlapping an object whose bounding box overlaps the tile border, and so the hilight *could* spill into the next tile.) While I'm holding down the LMB and moving the mouse, the cyan flashes on and off on alternating frames. This makes me wonder if the two trees are somehow not treated quite the same?

When I'm using shift-click to extend the hilighted area, I don't ever see the cyan bar. Again, this makes me wonder if it's a Chrome problem, rather than in Skia?

I've also seen the cyan bar alongside a run of non-hilighted tiles, and extend offscreen to the top of the document. (This is the only condition I can capture in a screenshot; see attached.)
Screenshot from 2013-04-04 10:46:03.png
211 KB View Download
Project Member Comment 3 by, Apr 4 2013
Chromium's only seems to download release executables; is it possible to hack it to get Debug? Or are those not archived? (I believe the latter...)
Project Member Comment 4 by, Apr 4 2013
This is a known problem.  Difference ops need to be treated as inverse-filled intersections as far as bounds computations are concerned, and inverse fills are not handled right.  I put this on the back burner because last time I looked, the clip usage patterns in WebKit were not triggering this bug.  I guess the CC is triggering it now.  I already have a partial CL for this that I can dust off.

Project Member Comment 5 by, Apr 6 2013
FWIW the complexclip_bw and complexclip_bw_layer GMs don't render correctly in tiled mode (please see  Issue 1198 : Tiled rendering of GMs fails (

This might be a simpler means of reproducing and debugging the issue.
Project Member Comment 6 by, Apr 8 2013
Project Member Comment 7 by, Apr 8 2013
Just checked, 1198 is not a dupe, although it has similarities.
Project Member Comment 8 by, Aug 26 2014
Labels: Area-Clipping
Project Member Comment 9 by, Aug 28 2014
Justin, this was flagged high priority and you've owned it for more than a year now. Has it been fixed? Should we look for somebody else to take it over?
Project Member Comment 10 by, Aug 29 2014
Hmmm... This totally fell off my radar. I guess the compositor worked around it? enne?
Project Member Comment 11 by, Aug 29 2014
We worked around it.  cc::PicturePileImpl no longer rasters its pictures in this way using kDifferenceOp.  Not sure anymore if this is still a bug.
Project Member Comment 12 by, Aug 29 2014
Labels: -Priority-High Priority-Low
No demand -> priority low
Project Member Comment 13 by, Dec 7 2015
Labels: Hotlist-Fixit
Sign in to add a comment