This test has been "failing" ever since we had native
replay of metasurfaces to pdf. But looking at the results,
they are actually superior to the image-backend reference
images.
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
This is now failing as we compute NAN font metrics for bitmap-only fonts under
disabled metrics hinting. A very infamous bug excercised with PangoCairo's PDF
output.
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.
I was experiencing very weird rendering problems and crashes in evince with
pixman 0.9.4. Upgrading to pixman 0.9.6 fixed the all. Lets just require it.
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.
