a2880699e8
The width parameter is used to disable the blit fast-path (memcpy) when
source and destination rows overlap in memory. This check was added in [0].
Unfortunately, the calculation to determine if source and destination
lines overlapped was incorrect:
(1) it converts width from pixels to bytes, but width is actually in
bits, not pixels.
(2) it adds this byte offset to dst/srcLine, which implicitly converts
the offset from bytes to sizeof(FbBits).
Fix both of these by converting addresses to byte pointers and width
to bytes and doing comparisons on the resulting byte address.
For example:
A 32-bpp 1366 pixel-wide row will have
width = 1366 * 32 = 43712 bits
bpp = 32
(bpp >> 3) = 4
width * (bpp >> 3) = 174848 FbBits
(FbBits *)width => 699392 bytes
So, "careful" was true if the destination line was within 699392 bytes,
instead of just within its 1366 * 4 = 5464 byte row.
This bug causes us to take the slow path for large non-overlapping rows
that are "close" in memory. As a data point, XGetImage(1366x768) on my
ARM chromebook was taking ~140 ms, but with this fixed, it now takes
about 60 ms.
XGetImage() -> exaGetImage() -> fbGetImage -> fbBlt()
[0] commit
|
||
|---|---|---|
| Xext | ||
| Xi | ||
| composite | ||
| config | ||
| damageext | ||
| dbe | ||
| dix | ||
| doc | ||
| dri3 | ||
| exa | ||
| fb | ||
| glamor | ||
| glx | ||
| hw | ||
| include | ||
| m4 | ||
| man | ||
| mi | ||
| miext | ||
| os | ||
| present | ||
| pseudoramiX | ||
| randr | ||
| record | ||
| render | ||
| test | ||
| xfixes | ||
| xkb | ||
| .dir-locals.el | ||
| .gitignore | ||
| COPYING | ||
| Makefile.am | ||
| README | ||
| autogen.sh | ||
| configure.ac | ||
| devbook.am | ||
| docbook.am | ||
| fix-miregion | ||
| fix-miregion-private | ||
| fix-patch-whitespace | ||
| fix-region | ||
| manpages.am | ||
| xorg-server.m4 | ||
| xorg-server.pc.in | ||
| xserver.ent.in | ||
X Server
The X server accepts requests from client applications to create windows,
which are (normally rectangular) "virtual screens" that the client program
can draw into.
Windows are then composed on the actual screen by the X server
(or by a separate composite manager) as directed by the window manager,
which usually communicates with the user via graphical controls such as buttons
and draggable titlebars and borders.
For a comprehensive overview of X Server and X Window System, consult the
following article:
http://en.wikipedia.org/wiki/X_server
All questions regarding this software should be directed at the
Xorg mailing list:
http://lists.freedesktop.org/mailman/listinfo/xorg
Please submit bug reports to the Xorg bugzilla:
https://bugs.freedesktop.org/enter_bug.cgi?product=xorg
The master development code repository can be found at:
git://anongit.freedesktop.org/git/xorg/xserver
http://cgit.freedesktop.org/xorg/xserver
For patch submission instructions, see:
http://www.x.org/wiki/Development/Documentation/SubmittingPatches
For more information on the git code manager, see:
http://wiki.x.org/wiki/GitPage