Composite and application compatibility

Mike Hearn m.hearn at
Thu Sep 2 02:23:45 PDT 2004

So, I guess the boat has sailed on this one? Is there no chance of the 
decision to use use an UNBREAK_ME_PLEASE environment variable being 

Mike Hearn wrote:

> Hi guys,
> I've been reading the archives of this list and am a bit concerned that 
> the introduction of X compositing will break backwards compatibility 
> with some important software.
> The first thread about this seems to have been the Flash/Mozilla issue. 
> The second suggests that some GTK 1.x apps can be broken.
> This is a serious amount of breakage, similar in scope to the problems 
> caused by the introduction of NPTL which mangled RealPlayer, the JVM and 
> Wine amongst many other high profile, popular applications.
> The recommended workaround seems to be to set an environment variable, 
> but I have severe reservations about this approach. It's been used 
> before, to disable NPTL for apps that didn't work with it, and has 
> several serious disadvantages:
> 1) You have to know about the environment variable in order to use it.
>    LD_ASSUME_KERNEL was never well documented until long after the fact.
>    Even if XLIB_SKIP_ARGB_VISUALS is well documented in man pages,
>    release notes etc, the vast majority of users will still be unaware
>    of it just through the nature of the thing.
> 2) You have to be able to diagnose the problem in order to use it.
>    For somebody who is not a programmer, this can be impossible. Often
>    I've only thought of using LD_ASSUME_KERNEL after putting gdb to work
>    on mysterious deadlocks and crashes. This is far beyond
>    the abilities of most Linux users who these days are usually not
>    developers. Even if the user *is* able to use a debugger there's no
>    guarantee that they will correlate BadMatch errors/crashes in Xlib
>    with the introduction of ARGB visuals much as many people could not
>    correlate crashes and deadlocks inside libpthreads with NPTL.
> 3) It's a pain in the ass to use. You have to write a wrapper script
>    for each program affected.
> 4) The vast majority of people can't or don't use them. Go read any
>    popular Linux (or even *BSD) tech support forum to see endless
>    threads full of people suffering through needless breakage.
>  From my understanding of the technology clients have to be specifically 
> written to use ARGB visuals anyway, so there's no harm in hiding them 
> from applications entirely unless they opt in. What is the problem with 
> having the developer do:
> XCompositeEnableARGBVisuals();
> before doing an XOpenDisplay or similar to prevent widespread breakage?
> In the Flash/Mozilla thread, this seemed to be the original intention 
> but was hard to implement because of bad interactions between XRENDER 
> and magically hidden visuals. If the visuals were simply ignored 
> entirely unless enabled before connect (ie even the composite APIs 
> couldn't see them) would this still cause a problem?
> This opt-in API could then be propogated up through the toolkits so ARGB 
> visuals are enabled on an app by app basis.
> What are peoples thoughts on this?
> thanks -mike
> _______________________________________________
> xorg mailing list
> xorg at

More information about the xorg mailing list