Xwindow Protocol

A standardized and mature NetworkProtocol? for GraphicalUserInterfaces.

The protocol is often confused with the WindowManager and WidgetToolkit?. This is due to the common Unix design goal of separating PolicyAndMechanism (window manager and toolkit vs. protocol and XwindowServer).

Not directly supported by the windowing system of Microsoft Windows or the Mac OS. MacOsx does ship with an XwindowServer (though the default GUI does not use it); X servers for Windows platforms are available (WindowsXwindowsServer).

The X protocol and Xlib, the official C programming interface to that protocol, embody several GraphicsPatterns, including AggregateGraphicCommands and BufferGraphicCommands.

The X protocol is not just mature but rather infirm! It's missing many features that are expected of modern graphics systems, such as alpha transparency, text drawn along paths, splines, anti-aliasing, sub-pixel precision coordinates, affine transformations applied to drawing operations, etc.

There's been support for anti-aliased fonts in X for a couple of years now via the Render extension -- http://www.freedesktop.org/~keithp/render/. The current release includes alpha-compositing via the Compositing manager and Damage extensions. The rest are managed by client side libraries, such as Cairo, for the most part. The XwindowProtocol is evolving rapidly now that freedesktop.org is involved.

In many applications, X is used as little more than an image transport, with drawing operations and compositing being performed in the client.

and in many other applications the full capability of X is utilized for vector-graphics rendering and editing

Mmm, I'm somewhat sceptical about that claim (of raster only use)... it's probably partly true for something like TheGimp. But even TheGimp uses ordinary X drawing commands for its user interface. You can hardly accept that X should be able to do all the graphical tricks TheGimp can do.

Ok, an image manipulation program can be expected to do most of its work in client-side images. But should PDF, Flash or SVG renderers? Or vector illustration packages? Or WhatYouSeeIsWhatYouGet word processors with anti-aliased text? Modern graphics APIs such as libart, Java2D and Qt render drawing operations on the client and ship the resulting images to the X server.

No-one has mentioned the in-efficiency of this protocol over the network where a packet is sent for every mouse click.

Mouse clicks are not a problem compared to mouse motion. However, on most systems it is drawing and blitting that is the bottleneck, not the transmission of events. Also, X lets a client filter out unwanted events at the server, so unwanted events are not sent over the network.

[Furthermore, some apps demand to see every mouse click, and if there's a lot of network latency, that's just too bad, in that context, no other networked GUI could get around that latency problem.]

[In the more general case, it's important to be aware of the Low Bandwidth X (LBX) extension(s) that make the average size and number of the network packets much slower.]

Actually, LBX is considered a failed experiment. You get the same benefit by simply compressing the protocol stream using SecureShell.

See WindowingSystems

X is being "fixed" in piecemeal fashion through means of extensions. Existing facilities in X are so inadequate, that core functions get replaced by extensions (fonts are an example - the existing font protocol regards font glyphs as nothing more than monochrome pixmaps). The logical conclusion of this approach is to simply make everything an extension, leaving X little more than a meta-protocol that negotiates sub-protocols and acts as a dumb data transport. Sadly, it's not terribly good at even those tasks.

Hmm. Complete backward compatibility while allowing protocol and server enhancement so clients can be incrementally upgraded. Sounds like a damn fine protocol to me.

Re "leaving X little more than a meta-protocol that negotiates sub-protocols and acts as a dumb data transport."

An exaggeration, but even to the extent it's true, or even if it were completely true, that's a strength, not a weakness, because that allows it to be endlessly extended with more modern ideas going forward.

Re "Sadly, it's not terribly good at even those tasks."

Oh? Name a (modern version of an) extension that is "not terribly good" at doing its extension. In fact, X11 extensions have worked out quite well over and over, specifically including extensions to support scalable fonts (e.g. Adobe Type 1), where originally only bitmap fonts were supported. There are no major problems with such extensions.

Critique on XwindowProtocolShouldBeStabbedAndBurnt

CategoryXwindow