The newly rewritten convex_quad code is actually simpler than the
triangle code being replaced here. This also allows us to throw
away the problematic _compute_x function which can't handle
horizontal lines, (divide by zero). So the cairo world becomes a
better place.
Use the new hook functions to register a callback for xlib to clear
the private glyph data when the display is closed. In order to do this
we need to reset the glyph cache inside the generic scaled font as well.
This patch adds a simple hook data type for a notifier style callback
and introduces two functions to manipulate a list of callbacks for
cleaning up on display closure.
This test started failing with the recent renaming of the following
three functions, (before they had no cairo in their names so they
were not getting picked up at all):
_cairo_test_fallback_surface_create
_cairo_test_meta_surface_create
_cairo_test_paginated_surface_create_for_data
With this change, the failure now goes away again.
The previous code was not handling all cases correctly, (yes,
even something as simple as a quadrilateral can exhibit a
remarkably large number of different cases when tessellation
is attempted).
This fix now introduces slope comparison which handles several
cases that were mis-handled with the previous implementation which
only used independent sorting of the X and Y values of the
coordinates.
This fixes the skew-extreme test case and the bug reported here:
Skew transforms were broken by the cairo update in December
https://bugzilla.mozilla.org/show_bug.cgi?id=373632
This is necessary to ensure that limiting backends using
CAIRO_TEST_TARGET does not increase the number of tests failing,
which is a desirable invariant.
This is more natural since cr->path can be used as if it was a pointer.
This means, for example, if we move on to making it a pointer, most of
the code using it does not need any change. So we get some level of
encapsulation of implementation details, if you prefer the terminology :).
This means, we have to malloc only one buffer, not two. Worst case
is that one always draws curves, which fills the arg (point) buffer
six times faster than op buffer. But that's not a big deal since
each op takes 1 byte, while each point takes 8 bytes. So op space
is cheap to spare, so to speak (about 10% memory waste at worst).
