When debugging a problem elsewhere, I saw a result where tesellating a rectangle x,=0, y=0, width=500 height=30 Gave the following three trapezoids: (gdb) p traps->traps[0] $31 = {top = 0, bottom = 1966080, left = {p1 = {x = 0, y = 0}, p2 = {x = 0, y = 1966080}}, right = {p1 = {x = 0, y = 0}, p2 = {x = 0, y = 1966080}}} (gdb) p traps->traps[1] $34 = {top = 0, bottom = 1966080, left = {p1 = {x = 0, y = 0}, p2 = {x = 0, y = 1966080}}, right = {p1 = {x = 32768000, y = 0}, p2 = {x = 32768000, y = 1966080}}} (gdb) p traps->traps[2] $35 = {top = 0, bottom = 1966080, left = {p1 = {x = 32768000, y = 0}, p2 = { x = 32768000, y = 1966080}}, right = {p1 = {x = 32768000, y = 0}, p2 = { x = 32768000, y = 1966080}}} Note that the first and third trapezoids are empty. I'd imagine this happens whenever tesellating this rectangle (and apparently a lot of others.. it wasn't the only rectangle causing problems), but I haven't tried to construct a standalone test case.
Move bugs against "cvs" version to "0.9.3" so we can remove the "cvs" version.
This is inherent to the tessellation stategy of _cairo_tessellate_convex_quad(). This overhead is now avoided entirely for single simple rectangles (with a special case tessellator). Empty traps are currently skipped when extracting regions, so extra work is being done and empty trapezoids are being rendered in the cases where the entire path can be represented as a region. However we know the form of the empty trapezoids that are most likely to be generated by our tessellators and so we can simply discard them just before appending them to the array. The oddity is that adding this early check generates subtly different results, for instance the 'elbows' of dash-curve. Argubably its an improvement, but at any rate this discrepancy looks like a bug in pixman.
(In reply to comment #2) > However we know the form of the empty trapezoids that > are most likely to be generated by our tessellators and so we can simply > discard them just before appending them to the array. > > The oddity is that adding this early check generates subtly different results, > for instance the 'elbows' of dash-curve. Argubably its an improvement, but at > any rate this discrepancy looks like a bug in pixman. What is "this" early check exactly? You've written some new code here, I assume? And it exposes a bug in pixman? How about sending that to the list, (and adding it to this bug report too I suppose---but the version on the list is what interests me more personally). -Carl
Created attachment 19275 [details] [review] Discard empty trapezoids Here's the patch I hinted at, it looks benign though the renderering artifacts leave me questioning whether I understand empty trapezoids.
(In reply to comment #4) > Here's the patch I hinted at, it looks benign though the renderering artifacts > leave me questioning whether I understand empty trapezoids. Well I solved my mystery - the issue was that for the trapezoids generated by tessellate_convex_quad() all the lines started/ended at top/bottom, which did not generalise to tessellate_polygon(). Fixed, pushed.
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.