Documentation?

[Patrick O'Donnell]

>From: Jim Gettys <jg at freedesktop.org>
>Date: Thu, 09 Apr 2009 19:28:15 -0400
>
>On Thu, 2009-04-09 at 19:08 -0400, Patrick O'Donnell wrote:
>
>> [compositing is] not really the same [as BS/SU], though, is it?
>> It's a bit disingenuous to claim that it's a simple substitution,
>> when in the one case the application merely sets a bit ... [versus
>> dealing with a separate module].
>> 
>> ... Nevertheless, one is given a free lunch for 20-odd years, then
>> suddenly one is made to work for it, it's natural to grumble a bit.

I had intended to, but obviously didn't, append, "even while
recognizing that the free lunch was a gift, not an entitlement."

>Except that if you were running this same application on anyone's
>default gnome or KDE environment (or several other window managers) you
>(or your customers) would never notice....
>
>And if you don't want to even change window manager and are using an
>antique without compositing support, just install and start running
>xcompmgr...

This sounds like the ticket, except: I may be missing something, here,
but the compositing window managers and xcompmgr just emulate backing
store for top-level windows.  In our case, we have descendents of the
same top-level window interacting.  So, it seems that while the work
to get automatic compositing enabled on our particular window that
needs it is not difficult, the complexities of dealing with the uneven
penetration even at this date of the composite extension in servers
and client libraries on all the platforms we're dealing with make it
more of a challenge.

Thanks for your comments and insights.  I have a much clearer
understanding, now, of how composite (and render and damage) can be
considered replacements for BS and SU, even if it's not one-to-one and
transparent.

		- Patrick