We've currently got a problem where it's easy to add a mutex
for a POSIX system and easy to forget to add its intialization
for other systems. Behdad has cooked up a plan for fixing this
properly:
http://lists.freedesktop.org/archives/cairo/2007-February/009679.html
In the meantime, we'll just kkeping breaking things, and patches
like this will be needed to fix up our mistakes.
This fix closes the following bug report:
cairo_font_face_mutex missing from cairo-win32-surface.c
https://bugs.freedesktop.org/show_bug.cgi?id=10175
Previously, an INVALID_RESTORE error would leave cr->gstate as NULL,
(which is generally impossible/invalid). This seems safe enough as
most cairo functions check cr->status first and bail if anything
looks fishy.
However, the many cairo_get functions happily march along in spite
of any current error. We could instrument all of those functions to
check for the error status and return some dummy value in that case.
But it's much easier to get the same basic effect by simply creating
a non-NULL cr->gstate which will hold all those dummy values, and
we can eliminate the crashes without having to touch up every
cairo_get function.
This fixes the bug reported here:
evolution crash to _cairo_gstate_backend_to_user()
https://bugs.freedesktop.org/show_bug.cgi?id=9906
It also eliminates the crash that was added to the nil-surface test
with the previous commit.
So it looks like it took us three commits before we finally got
all of the users of inner/outer switched to c1/c2. Hopefully
someday we'll have the compiler passing over all of cairo's
source code even if the backends aren't available to be run
on a particular system.
There was some leftover cut-and-paste description of get_font_face
in the documentation for get_scaled_font. That turned out to be a
good thing as it alerted me to the fact that the get_font_face
documentation was stale as well.
Add description of the 'nil' object return values, rather than NULL.
The trick here is that with the weak symbol support for pthreads,
pthread_mutex_init can be a NOP leaving the mutex uninitialized.
Then, if some pthread-using library is dynamically loaded, the
non-NOP pthread functions get used and we end up trying to lock
an uninitialized mutex.
This should fix the bugs reported here:
Cairo 1.3.14 deadlocks in cairo_scaled_font_glyph_extents or _cairo_ft_unscaled_font_lock_face
https://bugs.freedesktop.org/show_bug.cgi?id=10035
This reverts the following commits:
2715f2098167e3b3c53b
See this thread for an analysis of the problems it caused:
http://lists.freedesktop.org/archives/cairo/2007-February/009825.html
In short, a single cache for all backends doesn't work, as one thread
using any backend can cause an unused xlib pattern to be evicted from
the cache, and trigger an xlib call while the display is being used
from another thread. Xlib is not prepared for this.
That is, we always emit at least one page of output. Otherwise our
PS/PDF/SVG files would be corrupt, and output with zero pages does
not make much sense.
This means, PS/PDF/SVG do not need the final cairo_show_page() anymore.
If there is any drawing in the page, a cairo_show_page() is done
automatically.
Previously we were generating an image object with the desired
transform and then a pattern with only a translation. This means,
the pattern was alwasys axis-aligned. Obviously this does not
work correctly with repeated rotated patterns.
We now use an identity matrix for the image and put all the
pattern transformation (well, it's inverse) into the pattern.
This fixes the issue nicely.
The surface-pattern test is still failing even with a reference
image, because the gs rendering of the normal case and the
device-offset=25 case are different and both have seams.
With the hack in _cairo_pattern_acquire_surface to return a 2x2
surface for reflected patterns, we can now accept REFLECT surface
patterns natively in all backends. SVG was already doing that.
The PDF case needed some changes to go through
_cairo_pattern_acquire_surface. A similar change to the recent
change in SVG.
