|clipPath calls far from origin on huge canvases erroneously report empty clip|
|Project Member Reported by email@example.com, Sep 14 2012||Back to list|
What steps will reproduce the problem? 1. Record a very large picture with a clipPath >2^15 pixels from the origin, with some draws contained in it. 2. Play that picture into a second picture of the same size. 3. Play back the second picture, the contents of that clipPath will be missing (the clipPath call returned false, so the first picture decided to throw out that save/clip/restore block when playing back into the second). This seems to be a problem with SkRegion's scan-conversion of the path clips not working properly for paths that fall completely outside some limit (seemingly something like 32kx32k). This is only really a problem on *huge* canvases, which are uncommon outside of SkPicture records of large webpages, and render_pictures.
Sep 14 2012,
Aug 28 2014,
Dec 7 2015,
Feb 26 2016,
I'd like to trace through and see what's going on.
Mar 1 2016,
On second thought, I think it would be entirely reasonable to document that the clip is only guaranteed to work within a 2^15 pixel range. I suggest adding this to the SkCanvas::setClip* documentation. Or maybe, to accommodate this and bugs like bug.skia.org/554 maybe somewhere there can be meta documentation that sets the expectation that the device is limited to 2^15 pixels and that all device features also have that range?
Mar 2 2016,
Perhaps this will overlap with a different task I'm looking at : changing AA supersample size. This, in turn, is likely going to force me to actually implement path-tiling, so we can process a large path in chunks (tiles), keeping each chunk inside fixed-point range (for our edgelist).
|► Sign in to add a comment|