summaryrefslogtreecommitdiff
path: root/Development
diff options
context:
space:
mode:
authorAdamJackson <AdamJackson@web>2017-03-20 19:28:52 +0000
committerxorg <iki-xorg@freedesktop.org>2017-03-20 19:28:52 +0000
commita9b209e6b2cef2b117744a95e0e7f942f7674ceb (patch)
tree25c32d5470dc4f24556e330bcb9ea1e6903d8448 /Development
parent845e12f1f9d533c8a2e2fc964a70bd51910049f1 (diff)
Diffstat (limited to 'Development')
-rw-r--r--Development/Documentation/GlamorPerformance.mdwn6
1 files changed, 4 insertions, 2 deletions
diff --git a/Development/Documentation/GlamorPerformance.mdwn b/Development/Documentation/GlamorPerformance.mdwn
index e445a220..52d718d8 100644
--- a/Development/Documentation/GlamorPerformance.mdwn
+++ b/Development/Documentation/GlamorPerformance.mdwn
@@ -22,8 +22,6 @@ PutImage can't accelerate XYPixmap because that's not an image format that GL ha
PutImage (not ShmPutImage) tends to memcpy once more than a classic X driver because it buffers the image data into the GL command stream, where exa might just blast the data directly into the pixmap. It's difficult to get around this without either a hint to the GL that the upload should be immediate (with all the stall/flush that implies), or some _serious_ surgery to the protocol buffering code.
-GetImage falls back for ZPixmap with non-trivial planemask. There's not really a sane way to accelerate that through the GL, but it's cheap to fix up in software by just zeroing out the unset planes before writing to the client.
-
GetImage falls back entirely for XYPixmap, and again, GL very wisely doesn't believe in XYPixmap. Best approach is likely to download to a temporary as if ZPixmap, and then walk the planemask pulling out a plane at a time into the reply buffer. To do that one first needs to fix GetImage's calling convention so that a single XYPixmap get is responsible for all planes, not one at a time.
### Geometry ops
@@ -85,3 +83,7 @@ The GL sync extensions should be able to help us out with this, though on at lea
## Pseudocolor
Glamor doesn't accelerate drawing to pseudocolor at all. Probably a "good enough" solution would be to draw to the 8bpp surface in software as normal, and expand to 32bpp with a paletted texture (or equivalently, dependent texture lookups). Drawing to R8 directly would be... let's say "difficult".
+
+## Fixed since 1.19
+
+- GetImage for ZPixmap with non-trivial planemask is no longer a fallback.