Composite and application compatibility

[Mike Hearn]

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