New X Roadmap from Jim Gettys

A reader points to a roadmap on freedesktop.org that provides a good summary of what is out there for *nix desktops, with emphasis on X but also covering some other areas.

Comments

xouvert?

[ciaran_o_riordan]

For anyone that doesn't know:
The Xouvert Project
has been set up to help develop experimental extensions to X in an open way, using Free Software.
(It's not a competing X implementation, it is assistance).
(Jim didn't mention this in his paper)

Re:One cool thing in the roadmap...

[Gaza]

Xmove while ok in concept, it doesn't work that great in practice. I was able to get it to work on to Xsessions on the same machine, or two VNC Xsessions. But between an Xsession on a remote machine, or even the local Xsession and a local VNC Xsession it wouldn't go due to font and/or color depth incompatibilities.

Native support that addresses those issues would be great, I would love to run X apps in a screen like wrapper would I could attach them to any Xsession I might be located at.

Re:Bring it on

[jschrod]

Your attitude only shows your ignorance.

If an X users doesn't need network transparency, chances are very high that she doesn't use any code that is network transparency related -- this is the current default, after all.

In such situations, X applications communicate with the graphics subsystem over shared memory, just like in Windows. The difference is that the graphics subsystem is not part of the kernel but in user-space, and is called a server in tech jargon.

So, now that we have already what you want -- can you please step back and let the knowledgable people improve X at those places where it would really matter?

Re:question on your post

[dcuny]

In addition to standard RGB (red, green and blue information), you can include a fourth chunk of information: the transparency of a part of an image. This is referred to as the alpha, and together the tuple is referred to as RGBA.

In this scheme, you can specify to what degree a particular pixel is transparent, from 100% (entirely invisible) to 0% (entirely visible).

So alpha channel blending (or more simply, alpha blending) refers to the ability to combine two images in a way that includes transparency. From a user's standpoint, this means you can have windows that can be partially transparent, so you can partially see through them - a cool, but slightly disorienting effect. This is how it's currently done in Apple's OS X, and will be in the next version of Windows.

A matrix transformation is used to represent coordinate transformation. For example, rotations, translations (i.e.shifted along the X, Y or Z axis), or scaling (i.e.resized). Having this available to X11 means that these operations can be performed rapidly.

Of course, it helps if the graphics are in a format that allows these operation in the first place - that is, vector graphics (like Display PostScript, which Apple's OS X uses) instead of the traditional bitmaps. In a nutshell, bitmaps just specify the dots to display on the screen. You can resize them, but the result is you get an image made of big, chunky dots. With vector graphics, you specify the image as a set of points that the computer connects in a dot-to-dot manner. Since th computer draws smooth lines between the dots no matter how far apart they are, vector graphics can be resized and scaled without artifacts (i.e.weird side effects).

I, for one, welcome the spinning, scalable and alpha-blended X11 overlords.

Re:how about basic copy & paste?

[ChrisJones]

Umm, X's clipboard does work in a universal alt-c/alt-p type way (although some programs do have different bindings, e.g. ctrl-c/ctrl-p).
You are aware that the selection/middle-mouse buffer is not the clipboard at all, right? There is a completely seperate and proper clipboard, which is why most programs have Edit->Copy/Paste menu entries. People do tend to get confused and think the selection buffer is the same as the clipboard. IT IS NOT.

Re:One cool thing in the roadmap...

[runderwo]

xmove also doesn't support some of the more modern X extensions that are needed for toolkits to work. I think XRender was the one I had problems with.

Re:Stallman hates X-Windows

[penguin7of9]

But the take away message is that for all intents and purposes, XFree86 is X.

No, it isn't. X is a protocol and a standard, XFree86 is an implementation. What has happened is that the developers of XFree86 have become so influential that they, rather than the X consortium, set the agenda. But the X standard is, and continues to be, implemented by many different vendors and projects. It would be a sad day when X became synonymous with the XFree86 implementation.

Re:Bring it on

[nathanh]

As has been said many many times before, the network transparency does not affect the local transport. The X team amongst others have done tests (you know, where you measure things), and the implementation (using unix sockets, which are massively efficient data-transports, and shared-memory (no transport at all)) is as fast as you can get. It's within the theoretical margin of error of the peak performance of the system. Nothing goes faster.

Almost. Yes, the XFree86 UNIX socket is a very efficient transport. It doesn't add any measurable overhead compared to shared-memory transports (not the same thing as MITSHM, if anybody wonders about that). Solaris/X has a shared-memory transport IIRC, but the UNIX sockets on Linux are so damn quick it doesn't matter.

But that's not the whole story. There is still the marshalling/unmarshalling of the X11 protocol stream. That adds the same overhead no matter what transport you use. Direct rendering gets rid of that marshalling/unmarshalling wastage. That's why the OpenGL implementation on XFree86 uses DRI if at all possible.

There are also the context switches from the X client to the X server. Once again, direct rendering avoids those context switches because the X client fiddles the hardware directly.

My point is that XFree86 isn't as fast as is possible. We can get a lost faster. Direct rendering is one way to get massive improvements out of Xlib. So your statement "Nothing goes faster" is simply wrong.

X is massively efficient on the local channel. Direct-X on the PC is a different name for the same thing - an API into the low-level drivers.

No. No. No. Direct-X is a direct rendering infrastructure. On XFree86, only OpenGL currently enjoys direct rendering. Xlib is still sent over the socket so there is 1 (possibly 2) redundant copies, marshalling, unmarshalling, and context switches.

X itself is pretty bloody good at getting the maximum performance out of any hardware you throw at it - try running the 2-D blit in X11perf, then multiply the area * bitdepth * fps, divide by your AGP bandwidth and read the number you get .... You'll be surprised if you're running nvidia or ATI cards. Even venerable matrox cards push the bandwidth limit ...

And here's the perverse bit: you're right. I've been harping on about the Xlib in XFree86 not being as efficient as possible. I'm about to point out that it doesn't matter! Modern CPUs are so much faster than 2D GPUs or 2D framebuffers that XFree86 easily keeps them fully occupied. Even with all the XFree86 inefficiencies (conservatively estimated between 5-15% for most operations) the video card is still the bottleneck! So optimising Xlib in XFree86 is a waste of time... for now.

If the GPU/CPU ratios ever change then XFree86 will have to change as well, of course. For 3D this has already happened. The traditional method was client -> GLX -> transport -> server -> hardware. The GPUs improved so quickly that XFree86 needed a direct rendering infrastructure for 3D. Now the path is client -> OpenGL/DRI -> hardware. The Xlib path is still client -> Xlib -> transport -> server -> hardware. Maybe in the future we will see client -> Xlib/DRI -> hardware but for now, it doesn't matter, the hardware is already going flat-chat.

Re:Very interesting article

[Anonymous Coward]

Remember that this isn't the XFree86 group. Jim Gettys assists in the freedesktop.org project now. Keith Packard and the rest of the freedesktop crew are on their way to re-implementing/re-inventing X. Gone is the 15 year cruft of XLibs. XCB and XCL could result in some very nice performance boosts due to the reduction in round trip traffic.

Keith did a lot of research on running X apps over the network and noticed that one of the biggest problems was the number of round trips that apps such as nautilus and mozilla made. These round trips result in latency, which has a much bigger impact than bandwidth on the speed of remote apps.

freedesktop.org is also working on kdrive which is a new Xserver. Originally written by Keith for low memory embedded environments, it is being adapted for general use. Keith has also been working on adding off-screen compositing to the server allowing for OSX like effects plus a lot more.

XFree86 looks stagnant next to the work going on at freedesktop.org. This is where the community is at.

Re:There is no specific roadmap

[jg]

This is a work in progress.

I wasn't expecting it to get slashdotted.

Roadmaps show you where you were, where you are, and maybe where you are going.

I plan to do more on where things are going...

And it would be good if other projects did roadmaps of their own projects.

Re:how about basic copy & paste?

[ChrisJones]

For a fuller explanation of how the selection buffer and clipboard work, see this

It's a window system called X. It's not X Windows

[Russ Nelson]

Sigh. It's not X Windows. Never has been, never will be. It's a window system called X, or it's X11R6, or X11, or X, or The X Window System.
-russ