This fixes compilation of the xcb backend by porting commit e9c1fc31887c5bfbb's
changes from the image backend.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The additional time spent in the computation of tight extents for the
curve_to operation doesn't seem to be significant, but it makes the
extents computations faster and the approximations more accurate.
current_point and last_move_to were previously left in their old
position (which could lead to incorrect flag computation if other
operations were added to the path) and flags were not updated.
Only fill_maybe_region can change its value because the transformation
preserves vertical and horizontal lines, but can move the points and
make them integer if they were not or non-integer if they were.
Recomputing it is just as easy as checking if all the points are
integer and the path is fill_is_rectilinear.
Only fill_maybe_region can change its value because the transformation
preserves vertical and horizontal lines, but can move the points and
make them integer if they were not or non-integer if they were.
Recomputing it is just as easy as checking if all the points are
integer and the path is fill_is_rectilinear.
Instead of explicitly calling _cairo_fixed_move_to, setting the
needs_move_to flags is sufficient because the current_point is already
updeted correctly.
Clean up the code and make sure that _cairo_path_fixed_translate is
used whenever the _cairo_fixed_to_double rounding would result in the
matrix being approximated with a translation.
Now move_to's are actually added to the path when followed by a
drawing operation (line_to, curve_to or close_path).
This is implemented by updating the current_point and setting the
needs_move_to when a move_to operation is requested.
Whenever a drawing operation is requested and the needs_move_to flag
is set, a move_to is added before the drawing operation.
When a degenerate line_to is followed by a curve_to operation, the
line_to can be safely dropped, just like for degenerate line_to
followed by line_to.
The low-level line_to optimizations can be implemented in a more
abstract way using _cairo_path_fixed_penultimate_point and
_cairo_path_fixed_drop_line_to.
Instead of explicitly computing the flag in close_path, manually close
the path with a line_to, then drop the last operation if it is a
line_to (it might be another operation if the line_to was ignored
because it would have been degenerate).
Add a function to get the penultimate point and another one to drop
the last operation (assuming it is a line_to).
This allows some more abstraction in the line_to and close_path code.
Flags for the same path can be different depending on its "history"
(in particular if it was constructed and transformed they might be
different from what they would be if each point was transformed and
then the path constructed).
Make the hash independent of buf bucketing, extents and flags.
This makes the hash depend only on the actual content of the path, not
on how it is stored or on any computed property.
Use inline accessors to hide the flags in the code.
This ensures that flags that need additional computations (example:
is_rectilinear for the fill case) are always used correctly.
Remove _cairo_path_fixed_is_equal and use _cairo_path_fixed_equal
instead.
The latter function can recognize that two paths are equal even if the
drawing commands have been partitioned in a different way in the buf
list.
This fixes "text-rotate" in the test suite for the image backend and
"overlapping-glyphs" for the xcb backend.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The previous commit only added this option and made sure it gets set, but it
didn't actually have any effect. This commit now implements this option.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This ports commits 36b4b0631 and 7ab9ce1b9 from the image backend to xcb. Look
there for an explanation of why this is correct, I only copied this over and the
test suite said it was good. :-)
This fixes unantialiased-shapes, a1-rasterisation-rectangles and
a1-rasterisation-triangles.
Signed-off-by: Uli Schlachter <psychon@znc.in>
_cairo_xcb_surface_fixup_unbounded_boxes() calculated a list of boxes that it
has to clear to make an unbounded operator work correctly. Then it cleared the
boxes that were drawn instead of clearing the list of boxes that it has to
clear.
The reason that this wasn't noticed before is that there is an optimization in
case we have only one box instead of a whole list of boxes. This hid the bug.
This fixes the "unbounded-operator" test case.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Calling _cairo_xcb_surface_ensure_picture() on a XCB surface whose fallback
member is non-null is always an error. It's possible that the surface first gets
a picture assigned and later it's fallback member is set. In this situation,
it's still wrong to use the surface's picture for any drawing-
Signed-off-by: Uli Schlachter <psychon@znc.in>
Currently we print the backend description before every time, which is
overly verbose. As the information doesn't^Wshouldn't change, simply
print it before running the first test of each target.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The test for opaque gradients in _cairo_pdf_surface_add_pdf_pattern()
must be identical to the test in
_cairo_pdf_surface_emit_pattern_stops() other wise the PDF file will
reference a smask that does not exist.
The _cairo_pattern_is_opaque() test is too strict for PDF as PDF can
draw EXTEND_NONE gradients with opaque color stops without requiring a
smask.
