Still, it shows how fast X is progressing, now that we've ditched XFree86.

Since the split, X has really moved into the 90s, gaining <sarcasm>esoteric</sarcasm> features like monitor hotplugging, being able to configure more than one input device at once (like a touchpad and external mouse) and other silly things that nobody would ever want.

It's also jumped ahead of other window systems by leaps and bounds in some areas -- for example, multitouch support has been merged in, and X will be the first desktop window system to support multiple pointers, input redirection is on it's way, a new OpenGL framework (Gallium3D) is coming, new 2d acceleration (Exa/GEM/TTM/...) are in various states of merged-inness, etc.

And they've done all of this while deleting between 10,000 and 50,000 lines of code per release. And preserving backwards compatibility.

I'd say the future looks pretty bright for X.

[edit: give a better overview of what I mean by X progressing]

I just don't read posts like the one above. My brain literally refuses to bother anymore -- it scans the first couple of lines, sees the stuff it's already read, sees the repeated lines, and then starts looking around for something else to do.

The author's actual intelligence couldn't be better disguised if it came in the shape of a banner ad.

A short snippet that is being responded to puts the text in context, allowing the reader to see exactly what I'm going on about, without reading the article over and over, matching up what part, exactly, I'm responding to.

Sure, massive copy-and-paste is a waste of time, and obscures the post. However a lack of context, in my opinion, will make things even more confusing to the reader, especially in the case of the text that's being responded to being on a different page.

Ah well, each to their own.

My other problem with the point-by-point rebuttal is that all the chaff (in the form of those detailed but disconnected footnotes) threatens to obscure the bottom line, which in this case is "it isn't 2003 anymore and X has actually made a lot of progress since then". Basically, what I wanted to read was your second post. Which is much better than the first because it's written in prose -- connected sentences that speak in your voice and tell a story -- and not in chopped-up bullet points.

Now, if this were a detailed design review of a windowing-system project, things would be different, and I'd agree with you that your format is just fine.

Perhaps the issue here is that you obviously know and care a great deal about the design details of windowing systems, whereas I would rather read a short, colloquial summary of the state of play and then go to bed. ;)

Context is important, but the best approach is to integrate the context into the reply.

I'm coming from years of Windows lower-level UI coding (Win32/GDI/GDI+) and I wanted to look into Gnome/GTK+/Firefox drawing slowness (particularly with scrolling on weaker/older machines). I don't do much "pixel programming" at work, but I figured it would be fun side optimizing project to hack on.

An application will typically use a GUI toolkit like GTK or QT to do it's UI. This library will use Xlib[1] (or XCB[2] in some cases) to do it's event handling. Event handling in X consists of handling button clicks, sending messages to and from the window manager, cut and paste, etc. (The WM to app protocols are detailed in the ICCCM and the EWMH documents)

The painting will be done through a drawing library. for GTK apps (and Firefox, which isn't a GTK app, but does a good job of pretending it is through nasty hacks[3]) will use Cairo[4] to paint, and QT apps will use QT's paint engine (Arthur, I believe) to draw their UI.

Both of these engines will use XRender (which has largely replaced core X drawing) to actually put the pixels onto the screen, but works at a very low level (antialiased trapezoids and porter-duff compositing of images, more or less). They also fall back in software if the X server doesn't have XRender, or they've detected a buggy version of it.

That's the application side of it.

The fallback library that's used in Cairo is shared with the X server's software XRender implementation, and is called pixman[5]. Making this faster will likely make both the X server and the Cairo image surface faster.

Finally, the X server accelerates drawing to the screen through either the Exa accelleration architecture, or through XAA.

Exa is the more modern of the two, and it accelerates commonly used stuff that XRender wants for things to be fast. This mostly means alpha-transparent blends and such.

XAA is rather old, and is somewhat complicated to implement. Furthermore, it doesn't accelerate very much interesting stuff for modern apps -- when was the last time you saw an unantialiased wide line?

    [1] Xlib: the X protocol library and more. http://tronche.com/gui/x/xlib/
    [2] XCB: a new X protocol binding. Designed for transparent thread safety and asynchronousness: http://xcb.freedesktop.org/
    [3] Firefox renders GTK widgets offscreen, mashes them up, and paints them on screen in the XUL layer to pretend to be GTK
    [4] Cairo is a vector graphics library based of the postscript model: http://cairographics.org
    [5] Pixman is essentially a software implementation of XRender's drawing operations: http://cgit.freedesktop.org/pixman/

And it would make writing apps more difficult -- very few of them use entirely stock widgets, and it would be nearly impossible to securely and performantly implement new widgets on this system.

Plus, it's diametrically opposed to the X "Mechanism, not policy" mantra.

I wouldn't expect anything like this to take off, but it's been tried in the Y window system, and more interestingly -- and more dead-in-the-water -- in the NEWS window system.

That would allow existing apps and existing display servers, new apps and older display server, and old apps and newer display servers to work fine.

If both the app (at the toolkit level) and the display server are recent, however, remoting is massively sped up.

Notice that this is an old comment. Did all those features you describe exist back in 2003 on X?

Really? How would that be possible?

Don't get me wrong -- shared memory isn't always slower, but the constant and synchronisation overhead for a write() is smaller than an mmap(), so for small writes it can often be faster than shmem transport. For large writes, shared memory will usually be faster, of course.

Should be done once, at the beginning, and the segment re-used.

> then doing the interprocess synchronization

There is IPC anyway when you are sending information between processes. If you delve into the kernel you may be surprised at the number of layers of operations it takes to present data from one process to another using a socket.

> but the constant and synchronisation overhead for a write() is smaller than an mmap()

You're assuming the pages needed are already mapped in the former case. If you're writing anything of size, the pages will probably need to be faulted in anyway. If you're writing something small, then setting up your shared memory at the beginning and then re-using that memory is obviously the way to go, rather than getting and destroying shared memory segments every time you need them.

Perhaps they also wanted as much control as possible. Whilst they have done benevolent forks before (webKit) perhaps they thought that with X it would be unlikely to be taken well if they "had their way with it".

This is now 4 year old technology. Please flame with more current criticism. :)

It also makes sense with their view on antialiasing fonts (eg look at iphone DPI, it is close to print DPI).

I have an older iphone, I find its quite easy to read at that DPI, but the Neo DPI could be much better (I hear the kindle looks like reading paper, need to check that out, once again, we probably can't use it here yet !).

It sucks being in the "ass end" of the world sometimes.

That's awesome - I don't think I've ever seen a display that close to print quality. Its a pity the styling and software don't seem very consumer friendly.

Not sure where you got this but it's wrong.

Don't diss the pipe. It doesn't do everything, but if you're going to pick just one IPC mechanism, it's the one.

> Don't diss the pipe

I guess you've been smoking.

You don't make any sense when it comes to "buffers" (writing to shared memory IS writing to a buffer); a pipe doesn't give you a "big picture" to "properly optimize things" (a WTF "argument"), and no syscall is needed to "transfer control", unless you're talking about futexes or some other method to clue the kernel in, in which case, you do indeed have a way to clue the kernel in.

Writing once is faster than writing multiple times. That's why shared memory is obviously faster than not sharing and copying. Time needed to set up shared memory segments is negligible if done right -- once, at the beginning, and then re-used as needed.

Shared memory is fast, but it is just a shared memory. You have to synchronize accesses to it in some way.

When you want to transfer relatively small records from one process to another, it is probably faster to send them through pipe, because the copying overhead is negligible compared to synchronization overhead, which would be there in shared memory case too (and will probably be larger).

So to wrap up:

1) In most cases it is really needed to tell kernel that you are done and want to wait on some event in other process (relying on preemption or explicit timed sleeps to switch to other process is considered bad practice)

2) Writing once is indeed faster than multiple times, which is in this case of many small writes argument for pipes. Because pipe lets you hand over some data to kernel and let it do any low-level synchronization details, which it can generally do better.

3) In UNIX, pipes/sockets are the most flexible means of IPC. And in case where you have server that reads large chunks of data from multiple clients using shared memory, synchronizing accesses to this shared memory by sockets/pipe is good idea, because you can use select(2)/poll(2) on such socket. Using mutexes or semaphores or something like that would in most cases lead to busy-waiting or unnecessary convoluted code.

Pretty simple.

> it is probably faster to send them through pipe, because the copying overhead is negligible compared to synchronization overhead, which would be there in shared memory case too (and will probably be larger).

There is still synchronization overhead -- just because it's hidden from you in the kernel doesn't mean it isn't there. You should check out the source of your favorite kernel and see how much work is done behind the scenes to transfer data over a socket.

So you have an extra copy, PLUS extra synchronization overhead. The only reason people ever think that method is faster is because of operator error, e.g. creating and destroying shared memory segments thinking it's like malloc.

> 1) In most cases it is really needed to tell kernel that you are done

    man futex

> kernel and let it do any low-level synchronization details,

Look at the code. Really. It's a lot of overhead compared to userspace solutions.

> In UNIX, pipes/sockets are the most flexible means of IPC

s/flexible/common

Obviously shared memory is the most flexible because you can implement whatever scheme you want with it. There's always shared memory somewhere anyway, even with sockets, it's just hidden from you in the case of kernel code.

> Using mutexes or semaphores or something like that would in most cases lead to busy-waiting or unnecessary convoluted code.

Busy-waiting is done in multiple places in the kernel. If you're blocking on read anyway, what's the difference -- and if you're not, it's no more convoluted to check a shared condition variable on each pass than nonblocking reads and accumulations.