We can ensure that we always produce a clip region when possible by using
the rectilinear tessellator to convert complex, device-aligned polygons to
regions. Prior to using the tessellator, we relied on pixman's region code
which could only handle a union of rectangles.
For the frequent cases where we know in advance that we are dealing with a
rectilinear path, but can not use the simple region code, implement a
variant of the Bentley-Ottmann tessellator. The advantages here are that
edge comparison is very simple (we only have vertical edges) and there are
no intersection, though possible overlaps. The idea is the same, maintain
a y-x sorted queue of start/stop events that demarcate traps and sweep
through the active edges at each event, looking for completed traps.
The motivation for this was noticing a performance regression in
box-fill-outline with the self-intersection work:
1.9.2 to HEAD^: 3.66x slowdown
HEAD^ to HEAD: 5.38x speedup
1.9.2 to HEAD: 1.57x speedup
The cause of which was choosing to use spans instead of the region handling
code, as the complex polygon was no longer being tessellated.
The active edge list is typically short, and the skiplist adds significant
overhead that far outweigh the benefit of the O(n lg n) sort. Instead we
track the position of the last insertion edge, knowing that the start
events are lexicographically sorted, and begin a linear search from there.
We refactor the surface fallbacks to convert full strokes and fills to the
intermediate polygon representation (as opposed to before where we
returned the trapezoidal representation). This allow greater flexibility
to choose how then to rasterize the polygon. Where possible we use the
local spans rasteriser for its increased performance, but still have the
option to use the tessellator instead (for example, with the current
Render protocol which does not yet have a polygon image).
In order to accommodate this, the spans interface is tweaked to accept
whole polygons instead of a path and the tessellator is tweaked for speed.
Performance Impact
==================
...
Still measuring, expecting some severe regressions.
...
In order to handle 'cairo-perf-trace benchmark', we need to perform the
can_run? test on the directory name as opposed to the individual trace
names. Make it so.
I'd disabled this to look at cairo-qt performance, then forgot about it.
Be clean, cleanup globals -- this should fix the huge performance loss
when running in series multiple backends that need separate font caches.
These traces run for much longer than the original synthetic benchmarks
and seek to replicate 'real-world' applications, so the warning that the
xserver and cairo-perf are not bound to any cpu is false.
cairo-perf-chart takes multiple runs (currently it is limited to
prefiltered data sets) and pretty-prints a chart showing performace
improvements/regressions (in either ASCII or HTML) along with a
cairo-perf-chart.png
Use cairo_stroke() to perform the equivalent of
spiral-rect-(pix|non)align-evenodd-fill. A useful comparison of stroking
versus filling, as we can assume the composition costs are similar.
Oops we were accumulating paths during each spiral iteration and so the
tests were getting slower and slower and slower...
[And fix a couple of other instances of path accumulation.]
A common mistake is to forget to pass the foreground mode to
cairo-test-suite when launching it under the debugger, resulting in the
debugger not attaching to the children and missing the error you were
trying to capture. Under linux, we can inspect the path to our parent's
executable and if that looks like gdb, we assume it is and disable forking
of traces.
Add a command line option to the test suite to cause it to exit after the
first failure. The purpose of this is for integration into 'git bisect run',
where the failing test is unknown and we are looking for any failure. For
example, for use in a regression script to find commits in the midst of as
series that need a refresh of a reference image (or fixing!).
Cairo should include the contents of subwindows when using a Window as a
source but will clip to subwindows when using a Window as a destination.
This can be set using the GC's subwindow_mode.
XCopyArea and XFillRectangle can however only use one GC for both source
and destination. Cairo's mode is set to (the default) ClipByChildren.
This means that copying from a Window is broken, so we only allow the
optimization when we know that the source is a Pixmap.
The performance impact of this change has not been tested. It should be
small, as the code will use XRender otherwise.
If it turns out to be a bigger impact, the optimizations could be
improved by doing a two-step copy process:
1) Copy to an intermediate Pixmap with IncludeInferiors
2) Copy to the destination with ClipByChildren
(potentially omitting one one of the steps if source or destination are
known to be Pixmaps).
references:
commit 0c5d28a4e5https://bugs.freedesktop.org/show_bug.cgi?id=12996
Enabling 'FAST CLIP' appears to trigger an infinite loop so disable.
Enabling 'FAST FILL' has limited effect on performance, so disable whilst
the basic QT surface is improved.
Behdad pointed out that fprintf() returns a value so that we could simply
use the comma operator to return the correct value instead of the
expression-block gcc-ism.
As the associated is now explicitly the font-face used to create the font
by the user, whereas what we require is the current implementation
(quartz) font.
Infrequently, but, for example, handling glyph strings, we require the
string to be nul terminated. (Otherwise an error occurs, which was
previously compounded by a drastic leak.)
If we fail to add the glyph cache (presumably because the font is in
error) do not leak the allocation. As this occurs for every single glyph
string, the leak can grow very quickly and mask the original bug.
Currently the replay creates a fresh surface for every new surface. Whilst
using it to view replays (such as with --xlib) this is often not what is
desired so add a mode (compile-time only for now) to use similar surfaces
and blits to the front buffer instead.
font expects the dictionary to be constructed on the stack for its use, so
close it. (I missed the closing '>>' when switching between dictionary
constructors.)
Workaround for my arm toolchain which succeeds in linking the configure
program, only to complain when linking a program (such as cairo-perf)
against libcairo.so. Annoying.
