Compositing at the Xorg Developer's Conference

[Deron Johnson]

Another Xorg devconf has come and gone and this year I thought the
conference was especially good. It was especially interesting for me
because compositing was a hot topic of general interest and this is an
area I've been working in for a couple of years. It is great to see
that the solid foundation that Keith, Eric (and others) have laid down
in the form of the Composite and Damage extensions is being used in
new and interesting ways. I was also glad to hear that other people
are interested in pushing the boundaries of 3D composite managers.

Many companies gave presentations about their composite managers or
the work they are doing in the X server to provide additional
facilities for composite managers. David Reveman (Novell) talked
about his composite manager, GLX Composite, which is based on Xgl. I
particularly liked the part of his demo where he wrapped a window
around the edge of a cube. Kevin Martin and Soren Sandmann talked
about the composite manager that Redhat is adding to Metacity (they
used to call this "Luminocity"). I talked about the Hide/ShowCursor
extension to Xfixes (which allows a composite manager to render its
own cursor) and the Composite Overlay Window extension (which allows
composite managers to take over the whole screen without
interference). Keith talked about the Coordinate Transform Redirection
extension, which provides the necessary input hooks for screen
magnifiers and 3D composite managers.  (I'm going to take a liberty
and call it CTR, although Keith hasn't himself used this abbreviation).
Keith and I are planning to work on this in the next couple of
months with the goal of getting into into Xorg 7.1. (CTR is an
extension to the composite manager and the spec is in the
latest composite specification, which is in the CVS doc directory).

There were also presentations given by the 3D graphics folks about the
work they are doing to allow OpenGL (and Xvideo) apps to run inside a
compositing window environment. There also seems to be general
consensus on the need for a multi-vendor (EXT) extension to GLX called
GLX_EXT_texture_from_pixmap which provides an important performance
optimization--it allows a composite manager to render using a
composite backing pixmap as a texture.  On some devices, this will
avoid the need to copy the pixmap contents out of the server and
download them into a texture. Even on devices which still do a copy it
will reduce the number of copies that need to be done. It will also
make it transparent to the composite manager whether the device driver
is doing a copy or not. We had a good break-out session in which we
were able to resolve the synchronization semantics for this
extension. I am eagerly looking forward to trying it out.

With so many people interested in compositing managers I'm wondering
if the time is right to create a mail alias dedicated to discussions
on this topic. Clearly discussion about compositing features being
added to the X server itself should still take place on the xorg
alias, but I'm wondering if it might be a good idea to start an alias
focussed on the compositing managers themselves.  Here are some
examples of some of the discussion topics that could take place on
this alias:

    + Loose vs. tight coupling with the window manager.

    + Composite manager uses of screen magnifiers.

    + Effects plug-in architectures.

    + Scene graph libraries for composite managers.

    + Distributed scene graph mechanisms.

    + 2D and 3D client APIs for 3D apps

    + Mixing existing toolkits and 3D client APIs.

    + 3D Application interoperability between 3D
      composite managers.

    + Accessibility uses of compositing.

    + How to use CTR effectively for 3D

        I could post a white paper about how CTR
        can be used in a generalized 3D composite
        manager.

    + Input synchronization in 3D composite managers

	(I have some ideas in this area that I would
	like to discuss with others. Keith and I have
        tried to make sure that CTR can support a 3D
        version of X grabs, but the LG team isn't sure
        that this is the best approach. But we don't
        have any ideas for better alternatives. Maybe
        someone else out there has).

These are just some of the topics I can think of off the top of my
head. As you can see, the number of possible topics is very large. It
might be a good idea to take them off the xorg alias and put them into
a more specialized alias. This is not to say that compositing topics
of more general interest can't be posted to the normal xorg list, just
that those topics that are specialized to composite managers might
work better on a smaller alias.

I think it is clear that in the next few years the area of composite
managers are going to be a rich and fruitful area for research and
development. My goal, and the goal of the LG team, is to promote
collaboration and sharing among developers of Xorg-based compositing
managers. If we can avoid fragmentation, while preserving the ability
for companies to differentiate, we can make Xorg and Unix an exciting
and compelling environment for GUI developers.  Not only can we catch
up to Apple and Microsoft but I believe that we can surpass them. But
this will only happen if we combine our resources through cooperation.
I was buoyed up by the spirit of cooperation that I saw at the X
conference this year and I hope that it will continue in this vein.

So I am proposing a new alias called xorg-composite for discussing
issues specifically related to composite managers. Would anyone else
be interested in this?  If so, I volunteer to set it up. We will also
want a wiki page.