Composite and application compatibility
Mike Hearn
m.hearn at signal.QinetiQ.com
Tue Aug 31 07:36:33 PDT 2004
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
More information about the xorg
mailing list