I added this test originally to make it easier to debug
some recent bugs, (the test suite did have some repeating
in the checkered backgrounds, but with an offset of 0,
and then also in trap clip with an offset larger than the
surface itself). This test exercises repeating more directly.
It also triggers a bug in the PostScript backend that I've
not yet investigated. So the test does fail currently.
What was causing it was making all tests depend on all, to make sure
../boilerplate is built first. I'm not making all tests depend on
../boilerplate/libcairoboilerplate.la and ../src/libcairo.ls and added rules
to build those (by changing dir and making them).
This broke with the clone_similar optimization in
8d7a02ed58 The optimization added an
interest rectangle to clone_similar, but with a repeating source
pattern, the interest rectangle might not intersect the extents of the
surface at all.
The test suite caught this with the trap-clip case.
The fix here is to clone the entire surface if the pattern has an
extend mode of REPEAT.
This broke with the clone_similar optimization in
8d7a02ed58
The optimization added an interest rectangle to clone_similar,
but the acquire_surface path was neglecting to transform its
rectangle by the pattern matrix.
The test suite did catch this, but apparently we were too
distracted by the performance improvements to notice. Only
backends other than image that implemented clone_similar
would be affected by the bug, (which meant I only saw xlib
failures in my testing).
This fixes bug #8711
The previous change was in b62710d4f8
We just forgot to update the reference images at the time so there
have been false failure results in the test suite until now.
This corrects mosts of changes in clone similar commit. But it's
still a problem in _cairo_glitz_surface_set_image, it'll crash if
source region is outside image extents.
The previous changes in _cairo_glitz_surface_get_image causes test
clip-fill-rule-pixel-aligned and clip-fill-rule fail with a pretty
crash, this fix that.
This fixes a huge performance bug (entire image was being pushed to X
server in order to copy a tiny piece of it). I see up to 50x improvement
from subimage_copy (which was designed to expose this problem) but also
a 5x improvement in some text performance cases.
xlib-rgba subimage_copy-512 3.93 2.46% -> 0.07 2.71%: 52.91x faster
███████████████████████████████████████████████████▉
xlib-rgb subimage_copy-512 4.03 1.97% -> 0.09 2.61%: 44.74x faster
███████████████████████████████████████████▊
xlib-rgba subimage_copy-256 1.02 2.25% -> 0.07 0.56%: 14.42x faster
█████████████▍
xlib-rgba text_image_rgb_over-256 63.21 1.53% -> 11.87 2.17%: 5.33x faster
████▍
xlib-rgba text_image_rgba_over-256 62.31 0.72% -> 11.87 2.82%: 5.25x faster
████▎
xlib-rgba text_image_rgba_source-256 67.97 0.85% -> 16.48 2.23%: 4.13x faster
███▏
xlib-rgba text_image_rgb_source-256 68.82 0.55% -> 16.93 2.10%: 4.07x faster
███▏
xlib-rgba subimage_copy-128 0.19 1.72% -> 0.06 0.85%: 3.10x faster
██▏
The trick for this was to carefully ensure that the pen always has
at least 4 vertices. There was a previous attempt at this in the
code already but the test case had a combination of matrix and radius
that resulted in a value that was just able to sneak past the previous
check.
Type1 subsetting adds the .notdef glyph to the subset because the Type 1
spec requires that it be defined. However if the subset already has
256 glyphs, this will cause the Encoding vector to have 257 entries
which ghostscript does not like.
