|author||AdamJackson <AdamJackson@web>||2017-03-20 19:28:52 +0000|
|committer||xorg <email@example.com>||2017-03-20 19:28:52 +0000|
Diffstat (limited to 'Development')
1 files changed, 4 insertions, 2 deletions
diff --git a/Development/Documentation/GlamorPerformance.mdwn b/Development/Documentation/GlamorPerformance.mdwn
index e445a220..52d718d8 100644
@@ -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
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.