[clue-talk] Why X? [long, with provocative questions]

[Tom Witmer]

On Mon, 2005-04-18 at 21:31 -0600, Matt Gushee wrote:
[brutal snippage]
> So why is the desktop so slow? Perhaps part of the reason is poor code 
> in GNOME itself; maybe part of it is video card vendors not cooperating 
> with open source developers--though I gather that is much less of a 
> problem than it used to be. But, based on various things I've seen and 
> heard over the years, I can't help thinking that a significant part of 
> the problem is the venerable X Window System--in particular, the fact 
> that it is a client-server system.

   Hi, long-time reader, first-time poster here. I sympathize, but might
just pipe up a little bit in X's defense. X is absolutely not where it
should be, but it finally started heading there last year when it
escaped from under the thumb of the XFree86 group. The changes the core
developers have been working on now are all aimed at bringing X back out
of the stone age and into a place where it can do all the things it
should be doing now, with some serious hardware acceleration.

   Unfortunately, I would guess it'll be at least another year before
these fixes get polished enough for average desktop users to begin
taking advantage of them. That doesn't help you now, but maybe it'll
give you a sense of hope.

   In the time that I've been following the mailing list for X.org
( http://lists.freedesktop.org/pipermail/xorg/ ), I've picked up on a
lot of stuff that I didn't know before. In case they're of use, here are
the ones that really struck me, in no particular order (although
hopefully coherent -- I don't do well this late at night!):

     1. On a local display, X uses domain sockets, which add virtually
        no overhead. Remote displays can add overhead, but the network
        itself dwarfs that overhead anyway.
     2. The first rule of optimization is to not optimize anything until
        you have repeatable, quantifiable numbers that you can use to
        see if you've made things better or worse. In every X
        measurement I've heard of, the networking cost was still
        neglible for a local display. In other words, client-server
        isn't necessarily the problem here, unless it's in terms of how
        it affects the layout of the API. (I don't know enough about X's
        API to make an intelligent assessment about that.)
     3. Lousy video drivers, poor application design, and toolkits
        (Gnome, KDE) that do "too much" work in unaccelerated software
        usually _are_ bottlenecks.
     4. In the last year, X.org has produced the Damage extension, which
        greatly reduced the network traffic needed for remote displays,
        and (I believe) improved local performance as well by limiting
        screen redraws only to areas that actually need redrawn.
     5. X will eventually use 3D hardware acceleration for normal
        rendering, but that's at least a year away. (They're calling it
        Xgl at the moment, and recent activity on the list has been
        mighty encouraging.)
     6. Scalable Vector Graphics (SVG) and Compositing (translucency,
        drop-shadows, lots of wild eye candy) are on their way as well.
        SVG will provide some serious usability enhancements, as well as
        allow for even more wild eye candy. (Hey, some of that stuff is
        actually useful!)
     7. Graphic card vendors are finally starting to pay attention to
        Linux (and BSD, barely), so drivers are slowly getting better.
     8. The X.org team has been coordinating with other graphic library
        projects (like GATOS), so lots of missing functionality is being
        merged into the main codebase. This can be messy and slow, but
        was absolutely impossible under XFree86.
     9. Lastly, one of X.org's bigger improvements is to break up X's
        monolithic code base into several smaller components that can be
        worked on by smaller, more independent teams at a faster rate of
        change. That doesn't help us in the near term, but should help
        the developers quite a bit over the long haul.

   Once X.org is done playing catch-up, I think Gnome and KDE (and other
windowing toolkits) will be more than happy to defer much of their work
back to X instead of doing it so much through software. Unfortunately,
it all takes time and it just ain't ready yet. Keep watching though --
things are really happening underneath the hood.

 - Tom