Composite and application compatibility

[drag sidious]

I suppose stuff like that is why the composite exensions are disabled by
default on X.org 6.8 and require a user editing the configuration file
to turn it on.

On Thu, 2004-09-02 at 04:23, Mike Hearn wrote:
> 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 
> reconsidered?
> 
> 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 freedesktop.org
> > http://freedesktop.org/mailman/listinfo/xorg
> > 
> > 
> _______________________________________________
> xorg mailing list
> xorg at freedesktop.org
> http://freedesktop.org/mailman/listinfo/xorg