The code is checking a variable is non-NULL after it's already been
dereferenced in an assert.
I'm not certain whether the assert should be conditionalized to only be
tested when right != NULL (which would allow edges_end() to still be
invoked), or if the function should assert right as non-NULL always.
Coverity ID: #1160730
Signed-off-by: Bryce Harrington <bryce@bryceharrington.org>
Reviewed-By: Uli Schlachter <psychon@znc.in>
The code correct, but the compiler can't check that and thinks
there're uninitialized variables.
Perhaps we could rewrite it in a better way, so the compiler
can do better (even arch specific) optimizations.
Signed-off-by: Enrico Weigelt, metux IT consult <enrico.weigelt@gr13.net>
Signed-off-by: Uli Schlachter <psychon@znc.in>
den_det is positive because intersect_lines is called
only after _slope_compare returned > 0 and slope_compare
is returning the sign of den_det
The quadratic-time intersection finder is #if 0-ed out
in src/cairo-bentley-ottman.c, but is unusable even there
since the second commit to that file.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=74779
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Optimizing compilers aggressively remove code that is executed only
after an undefined behaviour occurred.
Also, the difference of two (non char) pointers hides an integer
division that, because the divisor is known at compile time, is
transformed into a multiplication by a pseudo-reciprocal, and in this
case the difference is not always a multiple of the divisor, resulting
in an invalid comparison predicate.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=74779
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
In Hobby's paper it is proved that INTERSECTION events can be
processed in any order by ignoring intersections between edges
non-adjacent in the active edges list.
But with respect to START/STOP events they must be processed in
order. Because START/STOP events have always exact y, it is
sufficient to know whether an integer y intersection is a
default/excess approximation of the exact to properly sort events.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=74779
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
When checking for continuations on the right-hand edge, the actual
direction of the edge is immaterial as it is sorted into ascending
y-order and the direction is fixed up when emitting into the output
polygon.
Fixes assertion introduced with 658fa75a5c.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
By simply swapping the continuation edges, we end up with a set of edges
that are defined over a shorter range than their extents. Whilst this is
numerically stable at our normal precision we start to encounter issues
when using a coarser grid during rasterisation as the derivative of the
edge becomes unstable.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44722
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to keep the bookkeeping in order, and so prevent a later
assert, we need to clear any edges when swapping the active edge order
upon an intersection event. The active edges are then reconstructed.
Fixes evince http://www.horizonhobby.com/pdf/BLH3500-Manual_EN.pdf
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Having spent the last dev cycle looking at how we could specialize the
compositors for various backends, we once again look for the
commonalities in order to reduce the duplication. In part this is
motivated by the idea that spans is a good interface for both the
existent GL backend and pixman, and so they deserve a dedicated
compositor. xcb/xlib target an identical rendering system and so they
should be using the same compositor, and it should be possible to run
that same compositor locally against pixman to generate reference tests.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
P.S. This brings massive upheaval (read breakage) I've tried delaying in
order to fix as many things as possible but now this one patch does far,
far, far too much. Apologies in advance for breaking your favourite
backend, but trust me in that the end result will be much better. :)
Step 1, fix the failings sighted recently by tracking clip-boxes as an
explicit property of the clipping and of composition.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
