Created attachment 70135 [details] Expected git bisect blames this commit: 36536d3eb83a8f942bcf1afba4d0815fbeaca10f is the first bad commit commit 36536d3eb83a8f942bcf1afba4d0815fbeaca10f Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Sep 27 11:14:18 2012 +0100 spans-compositor: Use the tight clip-boxes for polygon construction If we will be reducing the clip intersection to a single clip box check during construction, it helps if we use the tight clip box. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> The problem can be seen with altona_visual_1v2a_x3.pdf, there's a line in the middle of some radial gradients. I'm attaching the actual, expected and diff images.
Created attachment 70136 [details] Actual (since cairo 1.12.4)
Created attachment 70137 [details] Diff
Is this still an issue with latest git?
Created attachment 112021 [details] testcase The problem here is that filling twice the same area including partially covered pixels results in the first color being blended with the second in these pixels. The attached test case shows that the commit above exposed this limitation in the case of filling two paths clipped by the same vertical edge when the clip is a rectangle and the edge is not along an integer x and it shows that the behaviour is now consistent. It is possible to undo the rekevant effects of that commit by appending a '&& 0' to the if condition at line 1138 in src/cairo-spans-compositor.c: if (extents->clip->num_boxes == 1 && 0) {
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/cairo/cairo/issues/189.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.