Composite and Shared Memory?

[Owen Taylor]

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
> Composite?

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
                                                ||
                                                \/
                                           OpenGL texture
                                                ||
                                                \/
                                     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
avoided.

Regards,
						Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20041114/b382aef2/attachment.pgp>