On some architectures, gcc will emit a memcpy for structure copies which will
produce a valgrind warning when the source and destination pointers are the
same. Workaround this issue by explicitly checking the source and destination
for inequality before doing the structure assignment.
This patch also handles cases where r0 > r1, (one circle must still
be wholly contained within the other as that's all SVG supports).
This patch should also prevent a crash when r0 == r1.
It turns out that this case is extremely common and worth avoiding
the overhead of the path iteration and tessellation code.
The optimization here works only for device-axis-aligned rectangles
It should be possible to generalize this to catch more cases, (such
as any convex quadrilateral with 4 or fewer points).
This fix results in a 1.4-1.8x speedup for the rectangles perf case:
image-rgb rectangles-512 7.80 1.22% -> 4.35 1.62%: 1.79x speedup
▊
image-rgba rectangles-512 7.71 4.77% -> 4.37 0.30%: 1.77x speedup
▊
xlib-rgba rectangles-512 8.78 5.02% -> 5.58 5.54%: 1.57x speedup
▋
xlib-rgb rectangles-512 11.87 2.71% -> 8.75 0.08%: 1.36x speedup
▍
Which conveniently overcomes the ~ 1.3x slowdown we had been seeing
for this case since 1.2. Now, compared to 1.2.6 we see only a speedup:
image-rgba rectangles-512 6.19 0.29% -> 4.37 0.30%: 1.42x speedup
▎
image-rgb rectangles-512 6.12 1.68% -> 4.35 1.62%: 1.41x speedup
▎
xlib-rgba rectangles-512 7.48 1.07% -> 5.58 5.54%: 1.34x speedup
▏
xlib-rgb rectangles-512 10.35 1.03% -> 8.75 0.08%: 1.18x speedup
▏
With this change, the cairo-svg output is perfectly fine with
CAIRO_EXTEND_REPEAT, but is still very slightly wrong with
CAIRO_EXTEND_REFLECT, (though *much* better than it was before
this fix).
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
