Otherwise this may leads to an invalid memory access to r.
Fixes: Bug 18588 - XCB backend fails with missing render.
https://bugs.freedesktop.org/show_bug.cgi?id=18588
Signed-off-by: Julien Danjou <julien@danjou.info>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 834f1d7b70)
Sascha Steinbiss reported a bug where the PDF backend was reading beyond
the end of the glyph array:
http://lists.cairographics.org/archives/cairo/2008-December/015976.html.
It transpires that in the early glyph culling in the gstate we were
not updating the clusters to skip culled glyphs.
Repeat should be handled using MOD instead of '%' so that negative numbers
are handled as expected. E.g. -1 mod 600 = 599, not 495 as the '%' operator
gives. This was causing https://bugzilla.mozilla.org/show_bug.cgi?id=466258
Patch from Robert O'Callahan
Peter Hercek reported, and provided a very useful test case for, a bug
that caused his applications to crash with Cairo detecting an
non-invertible pattern matrix and thus asserting the impossible happened.
Bisecting revealed that the bug first appeared with 3c18d95 and
disappeared with 0d0c6a1. Since neither of these explain the crash,
further investigation revealed a compiler bug (gcc 4.3.3 20081130,
earlier versions have different bugs!) that caused the matrix inversion
to be invalid iff _cairo_matrix_scalar_multiply() was inlined (i.e. -O0,
or an explicit noinline atttribute on that function prevented the bug, as
did -msse.) So we apply this workaround to hide the bug in the stable
series...
The matrix is quite often just a simple scale and translate (or even
identity!). For this class of matrix, we can skip the full adjoint
rearrangement and determinant calculation and just compute the inverse
directly.
(cherry picked from commit 0d0c6a199c)
test/text-glyph-range was crashing since we requested the meta_surface but
the glyph wrongly believed it already had the meta_surface but was
checking for a path instead.
Adrian Johnson discovered cases where we mistakenly compared the result
of unsigned arithmetic where we need signed quantities. Look for similar
cases in the users of cairo_rectangle_int_t.
_cairo_gstate_backend_to_user_rectangle() requires that its input
arguments are non-NULL and describe the input rectangle to be transformed.
However, we were passing through output parameters from the public API
which were allowed to be NULL. So we need to allocate temporary variables
in which to compute the output rectangle, but only copy them as required.
If the image was opaque with no alpha channel, we filled the output alpha
with 0. Typically, the destination surface for dithering is an RGB window,
so this bug went unnoticed. However, test/xlib-expose-event is an example
where we generate an intermediate alpha-only pixmap for use as a stencil
and this was failing as the mask was left completely transparent. The
simple solution is to ensure that for opaque images, the output alpha is
set to the maximum permissible value.
This performance test relied on the recently-removed ability
to select the internal twin-based font family with a name of
"cairo".
Presumably, we'll want to bring this performance case back when
some other means of requesting that font face is added.
This test relied on the recently-removed ability to select
the internal twin-based font family with a name of "cairo".
Presumably, we'll want to bring this test case back when
some other means of requesting that font face is added.
It's not fair to steal this name from the namespace of family names.
There are definitely cairo.ttf files that exist out there, and people
may already be using these, (or may use them in the future), with
cairo_select_font_face and a family name of "cairo".
In place of this, we'll want to come up with some other new, and
documented API for selecting the internal font face.
This is just part of the make-distcheck routine for me. I know
Behdad added a test to check for missing images in the list, but
it doesn't seem to be getting run automatically as part of
'make test' nor 'make distcheck', (or if it it, then I'm not
noticing its output).
This avoids hitting driver-specific bugs in the X server, and is
better than doing 'DISPLAY= make distcheck' which simply disables
all xlib testing completely.
This target was added to the boilerplate during 1.8.1. It currently
shows many failures in the test suite. These failures likely fall
into three different classes:
* Tests needing new svg12-specific reference images
* Tests exercising bugs in librsvg
* Tests exercising existing cairo bugs
We haven't gone through the effort to separate these, but even for
the tests that are exercising actual cairo bugs, these are likely
bugs that existed in the cairo 1.8.0 release and not regressions.
Because of that, in this commit I'm conditionally disabling the
testing of the svg12 target. As soon as we increment the cairo
version to 1.9.0 or higher, this target will get re-enabled
automatically and we can begin the work to separate the tests as
described above and also fix the bugs.
A bit annoying that I have to add the same image as both -svg11
and -svg12 but that's all the support we have in the current
test suite. I suppose I could avoid doing that by figuring out
why this test case cannot successfully roundtrip through librsvg
and back through cairo.
These are quite similar to the existing ps3-specific reference images.
I definitely don't see any reason why this output should be considered
a failure.
This test is expected to fail due to a couple of known bugs. Chris
has fixes for both bugs, but is holding off on them until after 1.8.2
to prevent introducing any possible new bugs with his fixes.
Otherwise the reference image (user-font-image-ref.png) gets
interpreted as an image-specific reference image for the
user-font test case resulting in a bogus failure.
