Composite and application compatibility
m.hearn at signal.QinetiQ.com
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:
> 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
More information about the xorg