|author||AdamJackson <AdamJackson@web>||2018-06-12 15:25:20 +0000|
|committer||IkiWiki <ikiwiki.info>||2018-06-12 15:25:20 +0000|
Diffstat (limited to 'Development')
1 files changed, 3 insertions, 1 deletions
diff --git a/Development/Documentation/GlamorPerformance.mdwn b/Development/Documentation/GlamorPerformance.mdwn
index 84f9d0b6..936f2892 100644
@@ -14,11 +14,13 @@ Overlapping blits are hard for GL. We handle them by allocating a temporary the
This would have obvious interactions with DRI though.
+CopyPlane to a destination that's >1bpp expands the selected bit plane of the source through the GC foreground/background colors. You would need one or more of integer operation or a bitmap texture format to accelerate this, depending whether you wanted to accelerate just bitmap sources or arbitrary depths.
### Image ops
PutImage is implemented with TexSubImage2D, so is only accelerated for GXcopy operations. If LogicOp works, you could accelerate this by using a temporary texture and drawing through it to the destination.
-PutImage can't accelerate XYPixmap because that's not an image format that GL hardware (or anything postdating the Amiga, really) is equipped to deal with. You basically can't accelerate this unless you can accelerate arbitrary planemasks.
+PutImage can't accelerate XYPixmap because that's not an image format that GL hardware (or anything postdating the Amiga, really) is equipped to deal with. For 1bpp (equivalent to XYBitmap) you could plausibly do the color expansion in software to a temporary, or accelerate it if you had bitmap textures. For >1bpp XYPixmap it's a lot harder.
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.