This test exercises a clone_similar extents bug noticed by
Benjamin Otte. As expected, the xlib backend fails due to
that bug, (and interestingly, the ps backend is showing a
failure as well).
PDF backend sets /LastChar value in Type1C font dictionary incorrectly.
acroread then complains about incorrect /Widths in font.
The last char is numchars - 1, since it's zero-based.
The atsui font backend returned the internal 'unsupported' error
code for errors in operations that do not have fallbacks. Now that
the underlying cause, deleted glyphs, has been fixed, I'm changing
the status code returned to the public 'no memory' one; it should
be the only condition triggering the failure now.
If PKG_CHECK_MODULES fails, it does not print out any check results and so, no
newlines. This is kinda silly, at least in the case that no second branch is
provided, but I think that's the way it is, to let users decide what to print.
We now just do a AC_MSG_RESULT(no) and continue with what we used to do.
Inspired by Tor Lillqvist's similar change in Pango.
The warning happens all the place when the code converts from ullong to __m64.
The way the conversion is done is a C idiom: 1) get a pointer to the value, 2)
convert it to the suitable pointer type for the target, 3) dereference it.
That is "*(__m64*)(&m)" in this case. This is necessarily (as opposed to just
casting to target type) because the two types may not be "compatible" from the
compiler's point of view. Example of types that are not compatbile is structs
vs anything.
The "dereferencing type-punned pointer will break strict-aliasing rules" from
gcc exactly means: "some code may be assuming that pointers with different
types do not compare equal (or otherwise share the same target object). If
you case a pointer to a different type and dereference it, it may happen
here." However, in our usecase, it's clear that the compiler cannot make any
false assumptions. So we just go ahead and hide it by using a middle cast to
"void *". Since the compiler does not many any aliasing assumptions about
generic pointers, it will not warn either. (Though the problems if any, will
still occure. So this is not an ideal solution to this problem and should be
used very carefully, to no hide useful warnings for when things go loose on
some weird architecture.)
Another solution would have been to use gcc's "may_alias" function attribute,
but trying to define a may_alias version of __m64 hit a bug in gcc. That is,
try replacing "__m64" with "m64" and define:
typedef __m64 m64 __attribute__((may_alias));
and see it fail to compile. This seems to be because of the special vector
type that __m64 has.
The former workaround for the lack of non-repeating patterns in PDF
(as far as we can tell) was broken for a source pattern matrix that
resulted in scaling the source surface pattern down. This was
demonstrated by the failure of the scale-down-source-surface-paint
test which now passes.
The old code would have also allowed for bogus repeated pattern
instances to appear if the source surface pattern was translated
sufficiently far off the destination surface in just the right
direction. This bug is also fixed.
This patch adds options to disable the UTF-8 change bars and replace
them with ASCII '*' gfx. The motivation is that UTF-8 really does some
damage to some terminals, and some always forget to pipe stuff through
a pager to make it safe. The new options for cairo-perf-diff-files are:
--no-utf
--no-bars
This new test case demonstrates a bug in the PDF backend, (source
surface patterns are repeated even with a pattern extend of NONE).
Thanks to Romuald <mydevel@free.fr> and Claudio Saavedra
<csaavedra@alumnos.utalca.cl> for pointing out the bug.
Use a snapshot for the pattern, to avoid the pattern being freed undreneath
us before we actually render (as when rendering to a CG PDF context). Also
correctly return UNSUPPORTED from setup source, avoiding brokenness when
the source isn't torn down correctly.
Make these functions consistent with other cairo_get functions
by making cairo_get_dash_count return the count directly, and
removing the cairo_status_t return value from cairo_get_dash.
Instead, we can simply tweak the argument value for the last
MOVE_TO operation that's already at the end of the path.
This helps backends like pdf that are currently emitting all
of the redundant MOVE_TO operations in the output.
The implementation of _FbOnes in iccolor.c would not work on 64-bit
longs correctly. Fortunately, it's only used on integers, so make it
explicit in the declaration.
Use an inline function for the gcc builtin implementation to make sure
that it's never used with arguments of incorrect size.
There is no __INT_MIN__ in gcc 4.1.1, but it's not an issue now because
the argument is 32-bit.
Signed-off-by: Pavel Roskin <proski@gnu.org>
Adds a test for missing and out-of-range glyph indexes. The expected
ATSUI renderings are added as references, please replace these with
FT renderings when they become available.
We use a string pool plus lookup indices tables now, generated by perl code
embedded before the tables. The table in question is the default PS encoding
table, so no changes are expected in the future.
The patch implements a few more operations with special cases MMX
code. On my laptop, applying the patch to cairo speeds up the
benchmark (rendering page 14 of a PDF file[*]) from 20.9 seconds
to 14.9 seconds, which is an improvement of 28.6%.
[*] http://people.redhat.com/jakub/prelink.pdf
This also benefits the recently added unaligned_clip perf case:
image-rgb unaligned_clip-100 0.11 -> 0.06: 1.65x speedup
▋
image-rgba unaligned_clip-100 0.11 -> 0.06: 1.64x speedup
▋
All non-quartz surfaces need to fall back to using glyph surfaces,
in order to clip correctly. This second patch implements glyph
surface support, correcting the unclipped text seen in the clip-operator
test.
All non-quartz surfaces need to fall back to using glyph surfaces,
in order to clip correctly. The bug being fixed is visible in the
clip-operator test. This first patch takes out direct rendering support
for non-quartz surfaces, causing all image tests to fail.
I introduced this bug while fixing test glyph-cache-pressure
(commit 3b1d0d3519). I also changed
GLYPH_CACHE_MAX_HEIGHT and GLYPH_CACHE_MAX_HEIGHT to 96, then we
still can cache at least 28 glyphes per font(512 ^ 2 / 96 ^ 2).
This make us not hit slow path too much and improve performance
a lot.
Previously the code selected using the family name; this intermittently
selected a bold or italic face instead of the regular one. The new approach
is to select the desired font instance directly if possible, and only use
the family lookup if that fails. This isn't 100% correct but should always
provide the correct font instance for CSS generic font families. The
bug was sometimes reproducible with the select-font-face test.
