causing our search loop for evictable blocks to possibly skip a good
candiate, and another was the allocator would occasionally use
area->offset as if it was the base of the pixmap, while for a pixmap
that is not in available state, it is not. This caused some funny
miscalculation leading to overlapping pixmaps and accesses beyond the
end of the framebuffer. To make things cleared, I renamed save_offset
to base_offset, made sure it's the one used everywhere in the
allocator, and only align "offset" for the client at the end of
exaOffscreenAlloc().
hook so we can upload a subset of a pixmap, and convert the current
drivers to respect that. Use this support to directly UploadToScreen in
exaGlyphs, providing a 47.4% +/-2.4% decrease in wall time for ls -lR
programs/Xserver in an antialiased gnome-terminal on an M6 (n=3, caches
hot). I would have bumped major version, only I can't tell what the
EXA_VERSION_* is supposed to be doing as opposed to the module version.
around CPU access to the framebuffer. This allows the hardware to set
up swappers to deal with endianness, or to tell EXA to move the pixmap
out to framebuffer if insufficient swappers are available (note: must
not fail on front buffer!).
Submitted by: benh
simplify/clarify it for driver writers who probably don't want to know
what pPixmap->devPrivate.ptr or pPixmap->devKind mean. Converts the sis
driver to use them, and bumps the EXA module minor version.
