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.
This is a fix for a huge performance bug (as measured by perf/long-lines).
Previously, if no explicit clip was set, _clip_and_composite_trapezoids
would allocate a mask as large as the trapezoids and rasterize into it.
With this fix, it restricts the mask by the extents of the destination
surface.
This doesn't address the identical performance problem with the xlib
backend, which is due to a very similar bug in the X server.
image-rgb long-lines-uncropped-100 465.42 -> 5.03: 92.66x speedup
█████████████████████████████████████████████▉
image-rgba long-lines-uncropped-100 460.80 -> 5.02: 91.87x speedup
█████████████████████████████████████████████▍
The test passes an empty string to cairo_show_text, cairo_text_path, and
cairo_text_extents, and NULL and an invalid pointer, with zero num_glyphs to
cairo_show_glyphs, cairo_glyph_path, and cairo_glyph_extents.
When computing extents for an array of glyphs, just taking min/max of x/y for
the bounding box of each glyph doesn't work. The reason being that an
invisible glyph (like the space glyph) should not modify the resulting
extents, but it will. So now we skip invisible glyphs.
This custom stroking code allows backends to use optimized region-based
drawing operations for rectilinear strokes. This results in a 5-25x
performance improvement when drawing rectilinear shapes:
image-rgb box-outline-stroke-100 0.18 -> 0.01: 25.58x speedup
████████████████████████▋
image-rgba box-outline-stroke-100 0.18 -> 0.01: 25.57x speedup
████████████████████████▋
xlib-rgb box-outline-stroke-100 0.49 -> 0.06: 8.67x speedup
███████▋
xlib-rgba box-outline-stroke-100 0.22 -> 0.04: 5.39x speedup
████▍
In other words, using cairo_stroke instead of cairo_fill to draw the
same shape was 5-15x slower before, but is 1.2-2x faster now.
I must not have the right font available, (test result is coming out
looking like the result of ft-text-vertical-layout-type3, Vera?).
We should switch this test to load a bundled font, (should do that for
all font-using tests, too).
There is a race condition between glyph unlocking and glyph cache thawing.
Moving down _cairo_scaled_font_thaw_cache a few lines fixes the problem and make
crashes go away.
The glyph extent computation was totally busted. It was using "logical"
extents and it was not correctly handling rotations, etc. It all looks a lot
better now.
This test used to be named -truetype, which reflected the type of font used in
the test, in contrast to the -type1 test that uses a Type1 font. However, we
renamed this test to -type3 to emphasize the fact that a TrueType subset is
not emitted for vertical fonts and a Type3 fallback font is generated.
Now things have changed: we try generating a Type1 fallback font which is what
is happening for this test. Moreover, the -typ1 test also is generating a
Type1 fallback font since the Type1 subset font is not useful for vertical
fonts.
This fixes the last problem with vertical fonts in PS/PDF. As such, remove
ft-text-vertical-layout-type1 test from XFAIL and add PS-specific ref image
to pass.
The float version of many math functions were introduced in C99, and were
causing compile failure on systems like OS X. We now define them to their
double variant if __USE_ISOC99 is not defined. We may want to expand it later
to cover non-gcc compilers too, but since this is pdiff only, it's not really
important.
Previously we were defining a symbol INLINE and use that in one place, while
other places were using straight inline. With the AC_C_INLINE macro we can
just leave it to autoconf to correctly choose what inline should be defined
to.
The PS output for ft-text-vertical-layout-type3 looks correct, except for some
antialiasing mismatch. Ading ref image to fix this, and so, remove the test
from XFAIL.
