The NULL return value will only happen if the X Render extension
is not available. We've already got that NULL return value
documented, so it's not an error if the user asks for it. In
particular, it's definitely not a surface-type mismatch.
Thanks for Behdad for the suggested name improvement. Also, make
it more clear that the stride passed to cairo_image_surface_create_for_data
should come from calling cairo_format_stride_for_width with the
same width.
Document this function as a required call to get the correct
stride value before calling cairo_image_surface_create_for_data.
This means that previously-failing calls with non-multiple-of-4
stride values are now documented as errors. Also, we now have
the possibility of moving to more stringent alignment constraints,
(one can imagine doing 64-bit or 128-bit boundaries for example).
This Quartz API seems to only tile at integer coordinates; if the source image is
scaled to anything less than integer-aligned, seams appear between tiles. Detect
this and fall back to slower but more general CGPattern path.
The PostScript backend was generating image masks with packed mask
bits, when PS seems to expect each line of the mask to be padded out
to 8 bytes.
Ref: https://bugzilla.mozilla.org/show_bug.cgi?id=407360
In 02970ac8cf Vlad introduced the following
innocent-looking change:
- short min_x = INT16_MAX, max_x = INT16_MIN;
- short min_y = INT16_MAX, max_y = INT16_MIN;
+ cairo_point_int_t min = { CAIRO_RECT_INT_MIN, CAIRO_RECT_INT_MIN };
+ cairo_point_int_t max = { CAIRO_RECT_INT_MAX, CAIRO_RECT_INT_MAX };
Well, read it carefully... yeah. That caused each show glyph operation
upload a mask the size of the surface. With evince/poppler and certain
PDF files that each glyph is rendered in its own cairo_show_glyphs()
call, that meant a 20x slowdown in rendering a page of PDF.
If still wondering what's wrong with that change, here is the answer:
- cairo_point_int_t min = { CAIRO_RECT_INT_MIN, CAIRO_RECT_INT_MIN };
- cairo_point_int_t max = { CAIRO_RECT_INT_MAX, CAIRO_RECT_INT_MAX };
+ cairo_point_int_t min = { CAIRO_RECT_INT_MAX, CAIRO_RECT_INT_MAX };
+ cairo_point_int_t max = { CAIRO_RECT_INT_MIN, CAIRO_RECT_INT_MIN };
Yay for git-bisect.
First, seems like we were rejecting degenerate font matrix right away
at the constructor. Don't do that.
Next, PS/PDF were inverting the font scale matrix, assuming that it's
invertible. We now keep the inverse too, so they can use it. For the
case of a size 0 font, both the scale matrix and its invert are set to
0,0,0,0. That's safe, even if slightly inconsistent.
The data parameter from get_image was never really used; get rid of it and clean up
callers. Also get rid of a chunk of dead code in release_dest_image.
There were a few corner cases that the win32 surface was failing
at when there was an initial clip set; the win32-printing surface
had more serious problems when painting meta surface patterns.
This cleans up the initial DC clip tracking for both surfaces.
cairo_rectangle_int16_t was being used in a number of places instead
of cairo_rectangle_int_t, which led to memory corruption when cairo was
using a fixed point format with a bigger space than 16.16 (such as 24.8).
It's a common idiom to stroke degenerate sub-paths made with
cairo_move_to(x,y);cairo_rel_line_to(0,0) to draw dots. Test
that we get the desired extents from cairo_fill_extents,
cairo_stroke_extents, and cairo_path_extents for these cases.
Also document that the cairo_path_extents result is equivalent
to the limit of stroking with CAIRO_LINE_CAP_ROUND, (so that
these "dot" points are included), as the line width
approaches 0.0 .
This new function gets the extents of the current path, whether
or not they would be inked by a 'fill'. It differs from
cairo_fill_extents() when the area enclosed by the path is 0.
Includes documentation and updated test.
_cairo_path_fixed_bounds can use the new _interpret_flat mechanism; this
results in tighter bounds; previously the bounds followed the control
points of the beziers, whereas now they are the bounds of the curve.
