Composite and Shared Memory?
otaylor at redhat.com
Sun Nov 14 08:21:11 PST 2004
On Sun, 2004-11-14 at 11:00 +0100, Amir Bukhari wrote:
> it will be valuable if we could replace the off-screen Pixmap, which
> Composite created when Window redirect, with one we create at client
> side. this give us the ability to use Shared Memory Pixmap as
> off-screen, so we didn't need to copy the redirected window pixmap to
> our shared memory pixmap each time Damage occure.
> is it that possible to do currently or it must be there new change in
How does this work in conjunction with resizing windows? As soon as the
window is resized (larger), the X server is going to need a new Pixmap.
In the case of a combination window manager and compositing
manager, for override redirect windows, you could have a
"CompositeConfigureWindow" that along with the width/height took a
Pixmap to use as long as the window stayed that size.
But that would be moderately complex to implement, and is the short
term inefficiency really worth that complexity?
If you look at a GTK+ app redrawing with luminocity (I assume that
Looking Glass is similar), there's a lot of copying going on
GTK+ draws => Temporary double buffer
Offscreen redirected pixmap
ShmPixmap ----------- ShmPixmap
Texture in card / AGP memory
Just dropping *one* of these four copies isn't enough to make an
OpenGL CM production ready. If we want hardware acceleration for
drawing *within* windows (and that includes traditional OpenGL
clients and Xvideo) then anything that involves pulling image
data back into main system memory (like a ShmPixmap) needs to be
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part
More information about the xorg