Some composite questions

[Keith Packard]

Around 14 o'clock on Feb 11, Jay Cotton wrote:

     The main ingredient in translating DDX requests into memory
     pixmap rendering appears to be the use of pScreen->SetWindowPixmap
     to disconnect a window from its "screen pixmap" and connect it to
     the backing pixmap allocated by the extension. 

Yes, this is correct.

     but I don't see how this
     works for arbitrary DDXs.  The DDXs I'm familiar with do not
     do all of their rendering using the window's pixmap (which is
     ordinarily the screen pixmap.

It doesn't work for an arbitrary DDX, but it can be made to work 
relatively easily by changing acceleration code in modest ways.  I had to 
adjust the kdrive acceleration code to cover this case.

     Is the composite extension intended
     to deal with these kind of DDXs, or is it assuming that the
     X11 server will be configured to use a DDX which uses only
     memory rendering?

Oh absolutely not -- the goal is to take advantage of acceleration code 
which already supports rendering to pixmaps located in off-screen video 
memory.  Any extension design which precludes acceleration should be 
considered broken.

    Why does the composite extension do surgery on the visual list
    to add a 32-bit visual? What is this used for?

This new 32-bit visual is used for ARGB windows so that the compositing 
manager can use the extra 8 bits as an alpha channel for the window.

    The composite code makes a call to the mi routine
    miRegisterRedirectBorderClipProc. Was this added specifically
    to support the composite extension? The name would suggest it.
    Where can I find the source to this function?

xserver/mi/mivaltree.c.  This redirection allows the composite extension 
to control the clip region of the window within it's parent; the region 
contained within the window structure is reset to the size of the window.
This is how clipping within the window is not affected by siblings.

	The list has been quite on XFixes for a few weeks now, are you done
	changing it for the time being?  I'd like to start a port but don't
	want to have to 're-do' work.

Yes, I'm pretty sure XFixes is stable for now.  Let me know if there's 
anything in the extension which is troublesome; it isn't too late to fix 
stuff which can't be easily implemented in most X servers.

-keith