Since we're only doing software rasterization right now, anyway, it
makes more sense to just rasterize to system memory and then upload
to a pixmap once complete. This avoids expensive read-modify-write
cycles.
This results in a 2.4x speedup for a real-world test case that's
heavy on trapezoids, which is swfdec running on the following file:
http://michalevy.com/wp-content/uploads/Giant%20Steps%202007.swf
Many thanks to Chris Wilson for his cairo-traces repository and
cairo-perf-trace tool which makes it so easy to measure things
like this.
With glyphs sitting in per-glyph pixmaps, there's no reason to use the CPU
to move them to the cache pixmap, and lots of reasons to use the accelerator.
Signed-off-by: Keith Packard <keithp@keithp.com>
Without this, rendering component-alpha glyphs may break without a mask.
Bug #19534. Ported from fix by Michel Dänzer <daenzer@vmware.com> in
xserver commit 639f289dcdbe00a516820f573c01a8339e120ed4
This avoids prepare/finish_access_gc overhead when we're not changing things
(since GCTile is already handled) and get us the RW flag for the prepare on
of the stipple pixmap so thing will be synced correctly.
We can get a case with gnome-terminal + links, where we get two arrays
of glyphs all with 0 width and 0 heights in them. If this happens
we manage to get to this case without any buffer setup and segfault.
(cherry picked from commit 717c7492a0f6ba3fb3eabda33515881eef314155)
GCC isn't smart enough to analyze the control flow and figure out that
these are false positives, but initializing them shouldn't hurt, so work
around it.
This eliminates the cost of EXA migration management while providing full
pixmap allocation control to the driver. The goal is to make something
useful for UMA drivers.
Eric Anholt
Carl Worth
Alan Coopersmith
Keith Packard
Bernhard Rosenkraenzer
Dave Airlie
Jesse Barnes
Eamon Walsh