This fixes the failures of the new tessellator with the 3 tests:
bitmap-font, rectangle-rounding-error, and close-path
The problem was that identical edges from separate polygons
were not being added to the event queue, (because of a check
that was actually only intended to prevent an intersection
event from being scheduled multiple times).
This is the implementation as it cooked in the new-tessellator branch
available from:
git://people.freedesktop.org/~cworth/cairo
The file here comes from commit eee4faf79900be2c5fda1fddd49737681a9e37d6 in
that branch. It's sitting here not hooked up to anything in cairo yet,
and still with a main function with test cases, etc.
The files here are copied directly from the standalone skiplist module
available from:
git clone git://cworth.org/~cworth/skiplist
In particular the files come from the double branch and the following
commit on that branch:
8b5a439c68e220cf1514d9b3141a1dbdce8af585
Also of interest is the original skiplist module hosted by Keith Packard
that is the original implementation on which these files were based.
Since the cworth/skiplist branched off of keithp's, Keith has also
now implemented a doubly-linked variant which might be interesting for
further simplification of the code. See:
git clone git://keithp.com/git/skiplist
and the double-link branch there.
After changing _cairo_gstate_show_glyphs and _cairo_gstate_glyph_path to use
this function, we see a significant speedup due to the elimination of redundant
FP calculations.
An innocient-looking loop like this:
for (j = 0; j <= last; j++)
something();
cannot be optimized, because it may loop forever!
Imagine the case that last is MAXINT, the loop will never end. The correct
way to write it is:
for (j = 0; j < last+1; j++)
something();
In this case, if last is MAXINT, the loop will never run. Not correct, but
better than looping forever.
Still better would be to correctly handle the MAXINT case (even though it
doesn't make any sense to show MAXINT number of glyphs in one operation!) To
do that, we can use the fact that the input num_glyphs is a signed. If
there is one good thing about using signed int as input length, it's that you
can use an unsigned looping variable to avoid looping forever. That is
exactly what this patch does.
Optimizes EXTEND_REPEAT, especially when DDBs are in use through the
use of PatBlt or manually expanding out the repeated blits (up to a
limit). Will still fall back to fallback code as necessary.
Make sure that all operations are correct (the operations chosen
are listed in cairo-win32-surface.c); in particular, deal with the extra
byte present in FORMAT_RGB24 surfaces correctly.
Also adds support for calling StretchDIBits to draw RGB24
cairo_image_surfaces directly.
It turns out that all of the callers want a box anyway, so this
simplfies the code in addition to being more honest to the name.
(For those new to the convention, a "box" is an (x1,y2),(x2,y2)
pair while a "rectangle" is an (x,y),(width,height) pair.)
Optimize show glyphs by looking for strings of glyphs from the same subset
and use the xyshow operator to display. As a further optimization the xshow
and yshow operators are used for displaying horizontal and vertical text.
The bug was exposed by the recent addition of the paint-repeat test.
The ps output was crashing various interpreters by using infinite
extents for repeating patterns. Fixing that was easy enough, but
the offset of the repeating pattern was still being lost. The fix
for both involved imitating the style of emit_surface_pattern as
it exists in cairo-pdf-surface.c, (though the details are quite
different due to differences in the models of PS and PDF).
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
