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.
- 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.
There's no reason to not just dispatch this straight into the GC. As a
bonus, if you do so, damage wraps correctly, and thus swcursor works.
The side effect is it's no longer possible to override ShmPutImage with
ShmRegisterFuncs().
Also remove the (broken) damage tracking for same from EXA, since it didn't
work right, and is now superfluous.
It's buggy without Composite acceleration (leading to cropped glyphs) and not
really useful in that case anyway. The bug probably still needs to be found and
fixed for drivers that provide a PrepareComposite hook but can't accelerate
text rendering though.
Recording damage from other operations (e.g. creating a client damage record)
may confuse the migration code resulting in corruption.
Option "EXAOptimizeMigration" appears safe now, so enable it by default. Also
remove it from the manpage, as it should only be necessary on request in the
course of bug report diagnostics anymore.
When possible, use UploadToScreen() rather than CompositePicture()
to upload glyphs onto the glyph cache pixmap. This avoids allocating
offscreen memory for each glyph making management of offscreen
areas much more efficient.
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.
Add back exaGlyphs(); the new version copies the glyph images
onto a single large glyph pixmap and draws from their to the
destination surface. This reduces the management of small
offscreen areas and will allow us to avoid texture unit setup
between each glyph.
* Make sure available areas are considered to have no eviction cost. This seems
to help for https://bugs.freedesktop.org/show_bug.cgi?id=15513 but I'm afraid
that may just be coincidence.
* Only calculate eviction cost of each area once for each eviction pass.
Safeguard against potential (though unlikely) division by zero.
* Cosmetic enhancements: Name eviction cost related variables 'cost' instead of
'score' to emphasize that smaller values are better, update Doxygen file
comment to the way eviction works now.
In some cases we can still do the copying in hardware even if the
dimensions of the pixmaps are out of range. This is true when the boxes
that we're to copy are all in the card's range.
Reduce the cost of the inner loop, by keeping a set of pointers to the
first and the last areas in the series, subtracting the cost of the first
area from the score, and adding the cost of the last area while walking
the list. This commit also moves the scanning loop from exaOffscreenAlloc
into a separate function.
Idea by Michel Dänzer.
Replace the current score keeping algorithm with a rolling counter that's
incremented in ExaOffscreenMarkUsed, with the previous value being stored
in the area. exaOffscreenAlloc uses the difference between the counter
value and the value in the area when deciding which area to evict.
It now also takes the size of the areas into account, and favors evicting
smaller areas.
The credit for these ideas goes to Michel Dänzer.