New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 1209 link

Starred by 8 users

Issue metadata

Status: New
Last visit > 30 days ago
Area: Clipping
NextAction: ----
Priority: Low
Type: Defect

Sign in to add a comment

Tile grid clipping problems

Project Member Reported by, Apr 3 2013

Issue description

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