- By adding a small hack to the xserver i was able to easily test the performance of the normally rare direct case (using cairo).
- It turned out to be 70% slower for me (large test on an otherwise idle computer), which seems enough of a reason to remove it.
- AddTraps could also use a 2nd look, but since noone is using that it's a bit hard and less useful to test.
- Redo damage naming for more consistency.
- Call post submission functions only where appropriate.
- EXA can now live without it's odd damage workarounds.
Add a function to composite multiple independent rectangles
from the same source to the same destination in a single
operation: this is useful for building a glyph mask.
These hints allow an acceleration architecture to optimize allocation of certain
types of pixmaps, such as pixmaps that will serve as backing pixmaps for
redirected windows.
Exclude bits that will be overwritten from migration.
Use exaGlyphs even when Composite can't be accelerated, to avoid PolyFillRect
roundtrip via offscreen memory.
Initialize mask pixmap in exaGlyphs in FB in addition to system if the driver
provides Composite hooks to avoid migration overhead.
Remove manual damage tracking where superfluous.
Only migrate once in exaTrapezoids/Triangles instead of every time in
exaRasterizeTrapezoid/AddTriangles. Adapt manual damage tracking to new
infrastructure.
Also move definition of NeedsComponent() closer to where it's used.
The initiator of migration can pass in a region that defines the relevant area
of each source pixmap or the irrelevant area of the destination pixmap. By
default, the pending damage region is assumed relevant for the destination
pixmap, and everything for source pixmaps.
Thanks to Jarno Manninen for reassuring me that my own ideas for this were
feasible and for providing additional ideas.
miTrapezoids creates an alpha pixmap and initializes the contents
using PolyFillRect, which causes the pixmap to be moved in for
acceleration. The subsequent call to RasterizeTrapezoid won't be
accelerated by EXA, which causing the pixmap to be moved back out
again.
By wrapping Trapezoids and using ExaCheckPolyFillRect instead of
PolyFillRect to initialize the pixmap, we avoid this roundtrip.
This avoids some inefficiency in creating a temporary Picture
for every glyph at rendering time. My measurements with an i965
showed the previous patch causing a 10-15% slowdown for NoAccel
and XAA cases, (while providing an 18% speedup for EXA).
With this change, the NoAccel and XAA performance regression is
eliminated, and the overall EXA speedup, (before any of the
glyphs-as-pixmaps work), is now 32%.
Instead of system-memory data which prevents accelerated
compositing of glyphs, (at least without forcing an upload
of the glyph data before compositing).
* Defer to simpler hooks in more cases (inspired by XAA behaviour).
* Move damage tracking from lower to higher level functions.
* Always migrate for fallbacks.
Mostly due to exaDrawableDirty() now calculating the backing pixmap coordinates
internally, for cases where they aren't trivially known. There's a new
exaPixmapDirty() function for the other cases.
Also, rename to exaTryMagicTwoPassCompositeHelper() as it is now called for
non-component-alpha masks also, and add function description from
http://anholt.livejournal.com/32058.html.
through the whole CompositePicture stack and doing things like
computing damage over again. This is a sizeable win for text drawing
with a compmgr. Also avoid calling down into the server for dealing
with the scratch pixmap when we are able to do UploadToScreen
successfully and never need it.
down into an OutReverse and an Add. Turn off the fallback to software
glyphs when component alpha, now that we expect all (new) drivers to be
able to support it. Also, make Xephyr fall back in the CA Over case to
exercise this code. This speeds up my rgb24text and ls -lR in
gnome-terminal by a factor of 5.
and if they all have a maskFormat matching the format of the actual
glyphs If so, we can avoid the temporary pixmap for accumulating
glyphs, which reduces the number of operations done, and makes it
easier on the migration system. This fixes some significant performance
issues, particularly with subpixel antialiasing. Note that it does
increase the amount of damage computation which is done, so is not
always a win with a compositing manager running.
