>From: Jim Gettys <j...@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 _______________________________________________ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg