Composite and application compatibility
linlamer at cox.net
Sun Oct 24 00:04:44 PDT 2004
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
> 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
More information about the xorg