[Xorg] ARGB visuals from Composite extension
Keith Packard
keithp at keithp.com
Thu Aug 12 00:19:43 PDT 2004
The Composite extension creates an ARGB visual for applications to use in
constructing translucent windows. In the current implementation, that
visual is a part of the normal connection setup information, making it
possible for applications to discover the visual through the normal Xlib
methods.
However, this new visual is known to confuse the Flash plugin for Mozilla
(it assumes the Mozilla window uses this visual and crashes as a result).
So, to avoid this problem, I proposed that the Composite specific visuals
be hidden from the normal connection setup information and only made
available through an extension request.
So far, so good. Applications using core requests won't see the new
visuals, and applications using Composite will.
Now comes the tricky part.
Once an application has used the Composite extension to discover this shiny
new visual, it has to pass that visual structure around to create windows,
pictures and the like. Xlib is mostly happy to be handed some random
visual structure and so it mostly works. However, Xlib does believe that
it knows all of the available visuals, so extension functions like
_XVIDtoVisual will *not* find a visual structure from the new visual ID.
This turns out to be really bad -- the Render extension needs to locate
PictFormats associated with visuals, and it does so by locating the visual
based on the ID passed back by the X server. This means that applications
cannot locate PictFormats for these new visuals, which makes it pretty
hard to create Pictures for ARGB windows.
I don't know what other parts of the system assume that every visual is
stored in the Xlib visual structures.
My current kludge in the xlibs project is to report the visuals in the core
setup and then use a magic environment variable to hide these depth-32
visuals from mozilla.
I could hack Xcomposite to *modify* the list of Visuals held by Xlib so
that all of the existing Xlib functions work correctly. This will only fix
the Render problem if this Xcomposite function is called before the Render
extension is initialized. I could further hack Xcomposite to go mash the
Xrender structures as well. Yuck.
Right now, I'm leaning towards just leaving things as they are and
expecting that the Flash plugin will get fixed at some point, or that
we'll kludge Mozilla to handle the problem automatically.
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20040812/693a67a1/attachment.pgp>
More information about the xorg
mailing list