Slashdot Mirror

Modern applications will use the X Rendering extension. The Rendering extension was designed more than 10 years ago to replace the outdated rendering model of X. It was insprired by the network transparent windowing of plan 9 and specifically introduced with network transparency in mind.

http://keithp.com/~keithp/talk...
(see the conclusion)

A couple of benchmarks have been done over the past 2 decades. Though it's a shame they're not mentioned in the article.

The reference paper on the topic is Keith Packard's and Jim Getty's USENIX 2003 paper on LBX (Low Bandwidth X), a compression proxy for the X protocol. This paper compares LBX against the standard X protocol (both with and without a compressed SSH tunnel). A couple of key findings from the article:

• SSH compression is almost as good as LBX (which is probably why nobody bothers with it)
• X11 is pretty efficient on bandwidth for everything except raw image data
• X11 is very sensitive to latency

Now some of those issues have been (somewhat) mitigated in various libraries such as xcb, Qt and Gtk+, X11 can only be used comfortably over low-latency links.

While searching for that first article, I came across a more recent presentation which compares X11 against VNC and NX. Again, the author(s) conclude that X11's performance suffer greatly whenever latency increases. As for my own daily experience working company X terminals, remote X even on speedy gigabit networks is a major PITA and I'm planning to work on comparing alternatives (VNC, RDP, SPICE, ...)

X still has value, it's the lingua franca of GUI protocols on UNIX and I don't think anyone expects it to disappear anytime soon. But it is an antiquated protocol, both for local operations and for remote displays.

- As to overwriting. This occurs because the update events follow behind the UI. The problem is resolved by the composite extension, or by enabling backing store -OR- by increasing network bandwidth. Some old X Servers didn't have backing store (and certainly no compositing), AND ran over constrained pipes. It hasn't been a problem with desktop X for years.

- X is extensible by design. Multiple display support, accelerated 3D, video playback and compositing do work. For $DEITY sake, I use these features on my stinky little Acer Aspire One using Linpus! No particular problems -- "it just works" (tm). I don't like transparent windows, so I just don't bother, but it does work. Why the hell would a user want to know about the alphabet soup? Just use a packaged OS. The alphabet soup comes about because the development of X is an open process.

- And, in comparison with the Mac, you do notice that Apple packages an X Server with OS X? When running in a heterogeneous environment, it's necessary.

- Finally, you bring up the Unix Hater's Handbook. Ok, let's break it down:

1 - xload, xterm and xclock are possibly among the LEAST used programs under modern X based systems. They weren't
even installed on my Acer when I got it.

2 - Motif isn't used anymore.

3 - Cut and Paste really isn't an issue anymore, either.

4 - ssh -Y is usually used to remote X servers - authentication isn't an issue anymore either.

5 - Gnome and KDE provide the "customization methods"; since xterm isn't used anymore (or xcalc, or xedit),
the xresources issues are also gone.

6 - imake has been deprecated for YEARS.

7 - Pretty much nobody uses raw X protocol or XLib anymore either.

8 - NeWS was "killed" because IBM and DEC didn't want a repeat of NFS - they didn't want to send SUN any more money. So, they marketroids forced the issue. I agree the superior technology didn't win, but X is still around. Sucks to be the customer when they get what they have been told to ask for.

The UGH was relevant in the early '90s. No longer.

The "MAC UI Experience" could be planted on top of X. I am disappointed that Apple isn't driving that. It would involve developing several extensions that would be useful to X users. But, if Apple doesn't want to do it, others will:

http://www.freedesktop.org/wiki/Software/CompositeExt
http://en.wikipedia.org/wiki/XRender
http://keithp.com/~keithp/talks/randr/randr/
http://en.wikipedia.org/wiki/X_video_extension
http://docs.sun.com/app/docs/doc/801-6662/6i1196cd6?l=ja&a=view

The first four are generally implemented. The last is not (X/DPS). But, MAC OS X only implements a subset of X/DPS anyway (and, of course, it isn't compatible).

Congratulations Google, you've re-invented Low Bandwidth X!
Also see, An LBX Postmortem.

"The only serious improvement I've seen suggested over the X model is to provide a vector scene-graph API so that you can store the entire sequence of drawing commands in things like OpenGL vertex arrays in the GPU's memory. While this is a nice idea, it would require a radical redesign of all existing GUI toolkits and applications to be used to its full capability."

...

No it didn't. OS X uses the same rendering model as X11 with the Render and Composite extensions. Every window in OS X's window server is just an off-screen pixmap, just like X. The window server then composites them together. The only difference is that OS X hard-codes the compositing policy into the window server, while X11 separates it out into a compositing manager, making it easy to replace.

Quartz use a PDF like vector object model. With Quartz Extreme the whole thing is GLSL running on GPU. X itself don't have anything like that and have to use addon like Cairo. Since most X apps don;t use Cairo, even if there is a GPU accelerated Cairo, most apps don;t get any speed up.

Don;t know what's wrong with X? Read "Papers and Talks by Keith Packard":
http://keithp.com/~keithp/talks/

Kernel modesetting is a good thing, but there is no need to put the drivers into the kernel. KMS gets you lots of good things: BSoD (much better than the display freezing with no error message), flicker-free boot, and X could be moved away from needing to run as root.

As far as the drivers themselves, the best thing for them will be the move to the Gallium3D driver model, which will greatly reduce the amount and complexity of code needed to write a new driver. [1][2][3]

Keith Packard talks in his blog [4] about kernel mode drivers, but this seems to be KMS + memory management (GEM or TTM), not having, say, the entire Radeon driver in kernel. I guess it depends on how you define drivers. or maybe the difference between classic 2d drivers and DRM drivers (I have never figured out the details of that)?

>Today's X servers still support all kinds of usermode drivers, just so that 95% of configurations can thunk it all to the kernel.

All X drivers are usermode. There are graphics drivers that are in the kernel (fbdev), but these are unrelated to X.

Note: I am not a X dev or even a real programmer, but I follow X blogs, mailing lists, etc, and I try to learn as much as possible about X. If I am wrong about anything here, please correct me!

[1] http://www.tungstengraphics.com/wiki/index.php/Gallium3D
[2] http://akademy.kde.org/conference/presentation/9.php
[3] http://zrusin.blogspot.com/search/label/Gallium3D
[4] http://keithp.com/blogs/kernel-mode-drivers/

But it sounds like some of them are seemingly so well known. You've mentioned Dave Airlied and Keith Packard but what about Eric Anholt (Intel), Carl Worth (Red Hat), Daniel Stone (Nokia), Adam Jackson (Red Hat), David Reveman (Novell), Matthias Hopf (Novell), Alex Deucher (AMD), Ian Romanick (IBM), Alan Coopersmith (Sun). I believe that Tungsten Graphics also employ people who work on X (or X related infrastructure).

However do projects have to have paid devs to succeed? If there is the manpower perhaps paid people are not so key?

KeithP and and Jim Gettys wrote a paper on X network performance and the bottlenecks being seen a few years ago. Unfortunately I can't currently find a document discussing what the overhead of X's network transparency is (but I have a feeling it wasn't excessively high).

(Back home so I can reply logged in)

1. Representation schemes that are designed with specific knowledge of the type of data that is going to be represented compress better than a general purpose compression algorithm..

Yes, but not by much, unless you count destructive compression. HTML and other textual formats compress very well using general-purpose compressors (as one would expect). See for instance Keith Packard and James Gettys' LBX postmortem - ssh's built-in gzip compression is close enough to LBX's specialized X11 compression for it not to matter.

2. Broswers don't accept zipped pages, so the file would have to be manually unzipped before presentation to the broswer.

They do. Mozilla, Opera, and even Internet Explorer.

3. Broswers could be modified for either a binary HTML or to accept a zipped page, but there would be more run-time processing involved to unzip than there would be to natively support a binary HTML.

The performance impact is small enough for most people not to be aware that they are already using it. Unless you're on an ancient browser, you already are using it yourself - Slashdot has used gzip encoding for ages.

But perhaps I should expand on my original point ("man gzip" might have been a bit terse ;-) ): textual formats (roughly meaning files in some ascii-like encoding that use letters and punctuation for markup and text for data) are easy to work with, as text files have an astounding tool support. Specialized binary formats usually lack tools for anything beyond basic editing and viewing (wot - no AWK?).

The benefit of specialized binary formats is in parsing speed and file size, but the size part is not that important, since there are lots of good text compressors that let you get almost all the size advantage at almost none of the cost. The only thing left for specialized binary formats is parsing speed, but processing power stopped being the bottle-neck for most systems years ago (now it's about bandwidth, repeating the previous point).

Let's just let Keith Packard do the talking: http://keithp.com/~keithp/talks/usenix2000/render. html

MS started Avalon over D3D way back in 2003. I'm not contradicting your post, just making a factual observation.

Cairo, which is the closest Free Software equivalent of Avalon, also began back in 2003. However the comment you were not contradicting was about Vista, not Avalon.

They'll only make it X12 if and when they break that compatibility, and they won't do that without a good reason.

There's no requirement that an X12 server be completely incompatible with an X11 server. i.e. The X12 could easily accept commands from an X11 stream. While the X11 server would not be able to understand X12, such issues would be slow in cropping up, and X12 should easily be able to replace X11 long before that happens.

The extension architecture works fine AFAICS, is there an actual problem you have with it?

I can't speak for the parent poster, but my primary issue with current X-Windows is not so much the protocol (which could use a good overhaul anyway), and more the current design of X-Servers. Instead of forcing the OS to do its job, current X-Server designs schlep up video card, mouse, joystick, and other hardware control. The reasons for this design aren't entirely clear, but it is obvious that this is a source of many X-Windows issues. Moving these drivers to the OS level would improve reliability and configurability all around.

Don't take my word for it, however. Mr. Packard has a very good writeup on the issue.

4) Uncertianty in the display layer. Linux was almost exclusively XFree, now it's switching to Xorg, but hasn't completely. So driver developers are on the hook to support multiple upper level architectures on top of the multiple kernel architectures. Makes it even more complex.

That's because current implementation of X makes X server have a part in device management, which is both incorrect (device management should be kernel's problem, not user mode app's) and inefficient. The correct way to do this is to have the kernel take care of video mode switching and 2D/3D acceleration, exposing them through some common interface like OpenGL (so X would have no device-dependant code). See Getting X Off The Hardware for details.

You got me more interested in the issue, and I am currently reading a great article on this topic written by keith packard So unless you are Keith Packard, or have read it already, I highly recommend it.

...discussing the X11 OpenGL server at the LWE X BoF session. IIRC, the current problem with full native implementation of the OGL server is that starting the ogl server requires the dri layer...

Clearly, your real problem is that you were using too many abbreviations.

Come on, you X11 guys were the ones who showed that protocol compression adds complexity and doesn't improve efficiency much.

But you still can't write one sentence with fewer than 5 acronyms. Geez.

Yes, this is all using render, damage and composite, three new X extensions that do the bulk of the work on the server side.

I suggest you go to Keith Packard's talk at the upcoming linux.conf.au: The (re)architecture of the X Window System, etc.

The X.org people seem to be making good progress on updating X11 to suit modern hardware, while maintaining backward compatibility. If we threw out all our software every time the hardware changed we'd never get anywhere.

Damn straight. Cairo + Glitz is a very cool idea. We might also note that Keith Packard wrote a paper suggesting a revamp of the X server/driver model that integrates 2D and 3D ops a la (Arnholt's?) Xati server. XAA disappears and the hardware side of Mesa/DRI occupies that void as the whole thing goes GL (If I understand him correctly). So we could end up with a windowing system that can operate solely off SVG while fully utilizing GPU silicon.

The myriads of hackers on KDE and GNOME applications. I'm particularly fond of Kate, KDE's text editor, which is also a component in many other KDE applications.

Ward Cunningham, the creator of the original wiki idea, and Clifford Adams, the maintainer of one of the first usable wiki engines, UsemodWiki.

Rusty Foster, Dries Buytaert and Rob Malda, who created Scoop, Drupal and Slash, respectively, three very powerful weblog engines I use every day.

Spencer Kimball and Peter Mattis for starting the GIMP. Ton Rosendaal and the rest of the Blender team for proving that proprietary applications can become open source through distributed funding.

Anthony Jones, creator of iRATE, for exploring new ways to discover free music.

Dave Winer of UserLand for developing a simple content syndication format (now RSS 2.0), the MetaWeblog API and the XML-RPC protocol.

Keith Packard of HP for his many improvements to X.

Guido van Rossum for creating Python, Larry Wall for creating Perl and the many people involved in making PHP, and making it useful.

And of course, the many other people involved in all of these programs, and those who built the software infrastructure that made them possible.

Um, nevermind my heresay. See X Window System Network Performance, by Keith Packard and Jim Gettys.

I can't count how many times I hear on /. someone saying that X is too bulky, etc, etc. And here's Gosling saying (2 years ago) that X is headed in the direction of slim and lightweight. Am I misreading what he's saying?

No. You've read him correctly. What Gosling is saying is a simplified version of the X.org roadmap.

For example, X11 contains a font renderer. The design is really ancient. No anti-aliasing. Poor kerning. Clients couldn't access the glyphs very easily, which made it impossible to do arbitrary things like strokepaths or proper printing. It kind of sucked. A number of font extensions were considered for XFree86. Any one of them would have addressed all of the existing issues but they were heavyweight solutions.

So in the end Keith Packard wrote a better solution. He implemented the XRender extension. This extension simply knows how to draw rows of glyphs. It also knows about alpha masks (Porter Duff compositing). The client now turns the font (typically TrueType) into alpha-masked glyphs and sends the glyphs to the X server. If you're using a GNOME or KDE desktop with antialiased fonts then you're using Keith's XRender extension and client-side font rendering instead of the X11 font renderer. This is only practical because the client-side libraries (eg, libxft2) are shared.

Another interesting example of "slimming down" the X server is the Composite extension. Rather than implement a heavy compositing engine in the X server, Keith designed this extension so it simply renders the window into offscreen memory. Another extension, XDamage, tells a special client called the "compositor" when any region of the window changes. The compositor then uses the XRender extension to render the damaged region with appropriate drop shadows and/or alpha masks. Notice how the rendering is still done by the X server so it can be hardware accelerated.

For the future of X.org there is more of this "slimming down" being planned. Jim Gettys and Keith Packard gave a presentation in July 2004 where they suggest the future of X is as an OpenGL client. They are both keen on a new design where the X server stops being the arbitrator of video hardware. Instead it becomes an OpenGL client with direct access to the video hardware through the DRM, just like every other DRI client. There is a simpler version of that paper in the short slideshow Life in X Land.

I can't count how many times I hear on /. someone saying that X is too bulky, etc, etc. And here's Gosling saying (2 years ago) that X is headed in the direction of slim and lightweight. Am I misreading what he's saying?

No. You've read him correctly. What Gosling is saying is a simplified version of the X.org roadmap.

For example, X11 contains a font renderer. The design is really ancient. No anti-aliasing. Poor kerning. Clients couldn't access the glyphs very easily, which made it impossible to do arbitrary things like strokepaths or proper printing. It kind of sucked. A number of font extensions were considered for XFree86. Any one of them would have addressed all of the existing issues but they were heavyweight solutions.

So in the end Keith Packard wrote a better solution. He implemented the XRender extension. This extension simply knows how to draw rows of glyphs. It also knows about alpha masks (Porter Duff compositing). The client now turns the font (typically TrueType) into alpha-masked glyphs and sends the glyphs to the X server. If you're using a GNOME or KDE desktop with antialiased fonts then you're using Keith's XRender extension and client-side font rendering instead of the X11 font renderer. This is only practical because the client-side libraries (eg, libxft2) are shared.

Another interesting example of "slimming down" the X server is the Composite extension. Rather than implement a heavy compositing engine in the X server, Keith designed this extension so it simply renders the window into offscreen memory. Another extension, XDamage, tells a special client called the "compositor" when any region of the window changes. The compositor then uses the XRender extension to render the damaged region with appropriate drop shadows and/or alpha masks. Notice how the rendering is still done by the X server so it can be hardware accelerated.

For the future of X.org there is more of this "slimming down" being planned. Jim Gettys and Keith Packard gave a presentation in July 2004 where they suggest the future of X is as an OpenGL client. They are both keen on a new design where the X server stops being the arbitrator of video hardware. Instead it becomes an OpenGL client with direct access to the video hardware through the DRM, just like every other DRI client. There is a simpler version of that paper in the short slideshow Life in X Land.

using a GPU's 3D graphics processing power rather than the traditional 2D blitter.

• Cairo provides a vector-based rendering API with output support for the X Window System and local image buffers. PostScript and PDF file output is planned. Cairo is designed to produce identical output on all output media while taking advantage of display hardware acceleration through the X Render Extension.
• 
  
  Cairo provides a stateful user-level API with support for the PDF 1.4 imaging model. Cairo provides operations including stroking and filling Bézier cubic splines, transforming and compositing translucent images, and antialiased text rendering. The PostScript drawing model has been adapted for use within C applications. Extensions needed to support much of the PDF 1.4 imaging operations have been included. This integration of the familiar PostScript operational model within the native application language environment provides a simple and powerful new tool for graphics application development.

(Wow, great post.)

One of the good parts of Eric Rayrnond's new book The Art of Unix Programming is the discussion of protocol design, and in particular the foolishness of trying to squeeze out every single bit.

In particular, he points out that it's often better to just use a simple encoding, and then run a compressor like LZO or GZIP over the whole thing. This lets you design a simple protocol, and you get the benefit of compression over the whole thing rather than just the metadata. Complexity, of course, is the enemy of security. It is both simpler and gives better compression; and people with more network than CPU can turn compression off or down.

Keith Packard has some similar papers looking at X11, where he concludes that clever tricks like Low Bandwidth X really don't help all that much compared to just using SSH compression.

Latency is a different and harder problem, but one that's often better solved in the high-level design than by bit-banging.

this is rated intersting?

stop being ignorant!

I would argue to say that fonts on MY linux box look a hell of a lot better than a windows box. they are ALL antialiased. it's pretty.

why is it always A.C.s I get into arguments with.

Well, I've only gotten as far as the critique of X at the start of Thomas' paper. This critique is a classic /. "X sucks" troll in academically semi-polished form.

Point by point:

• X has too much latency: See Packard's paper in Freenix 2003: high latency is not an inherent X attribute, even over high-latency connections.
• X requires a toolkit for ease of programming: Duh. As opposed to what, exactly?
• X needs standardized UI semantics: This is moot. You may use X+Gnome or X+KDE if this is what you desire. Either is a fairly good and fairly complete system with standard UI semantics. The existence of two such systems is no more troublesome than the simultaneous coexistence of Windows and MacOS.
• X is "an incoherent mess": When making this argument, it is always useful to confuse the protocol with the implementation. The existence of Kdrive is a nice example of how much the latter can be cleaned up. The protocol hasn't changed in 20 years except for extensions: the argument that the extensions don't work together is supremely unconvincing, supported by one lame example. freedesktop.org has made a lot of progress in a short time in refactoring and standardizing X.
• X is complex: It is. Unfortunately, it is a response to complex application requirements. Again, one lame example involving perhaps the most demanding application running is cited. And again, freedesktop.org is standardizing mechanism for dealing with the cited problems.

It's perfectly valid to want to write a new window system. I can think of a variety of justifications, starting with "it's nice to try something different" and "I wanted to learn some things". Trolling is hardly necessary, and hardly welcome.

In case anyone is fooled by the baseless criticisms of X given by the regular troll above, here is a brief rebuttal.

• "1.Too much focused on 2D user interfaces, no native transperency for multimedia, low level and optimized applications."

Most major computer operating systems have 2d user-interfaces, but this doesn't matter because applications provide their own 3d user-interface if they really need one. Another reason may be that there are very few genuine 2D users who can satisfactorily project themselves onto a 3d user interface. Transparency is not a major requirement for X because those rare applications which require it can implement it themselves e.g. using GIF or PNG transparency. There is also going to be a transparency extension for X

• "2.Too little scalability between devices with varing performance and ability."

Not true. X runs fast, and much faster than Microsoft Windows 95, on my old i486 PC with 8MB RAM.

• "3.No sufficient support for disabled user enhanching devices."

This is a problem not of X itself but of the hardware manufacturers not writing device driver modules for XFree86. When enough people run Linux desktops in the opinion of the hardware manufacturers, device drivers for XFree86 will be written.

• "4.Severe security issues in the protocol. Especially no encrypted operation at NATO standard SECPROT level 4."

This has been nominated for Top 10 Absurd Comments on Slashdot. With a properly configured firewall, this is irrelevant because nobody on the internet can attack your computer's X display. By using ssh for securely forwarding X11 connections most attackers will be unable either to watch or to disrupt your X session.

• "5.Network protocol too bloated and complicated."

Very few people ever use the X11 protocol over a network, firstly, because most people who use X are using it for X applications running locally on their desktop computer, and, secondly, because anyone wanting to run X applications on a remote computer would use an X11 protocol compressor. The X11 protocol is complicated because it is powerful and easily extensible. As an aside, most intelligent people don't seem to have much trouble understanding the X11 protocol or the various extensions.

• "6.No smooth integration into the operating system."

That would be a very bad idea. Increasing the complexity of the interfaces between vital system components such as the kernel and X is a recipe for worse security, worse compatibility, and worse maintainability.

• "7.No smooth integration of the window managers."

Integration with what? X? The whole point of separating window management from X is to give you the freedom of choice to use whichever window manager you like. You can even change the window manager without having to reboot the kernel or re-start X. Otherwise, if you don't like using window managers, use GNOME, or KDE, or return to MS-Windows.

• "8.No stream compression in the protocols."

You don't seem to have heard of NX for real-time X11 protocol compression which typically achieves a 1000:1 compression ratio, of the ancient LBX, or of Differential X Compressor

So can anyone address how this new product is any different or better than Low Bandwith X?

Despite its complexity, LBX isn't much better than SSH compression.

Basically, LBX is crap at reducing round-trip operations. About the only real value in LBX is the compression, which is something you could also get from an SSH tunnel (and indeed SSH tunnel's can /beat/ LBX). However the real killer to X performance is latency, even if you have plenty of bandwidth, X will react very poorly in the face of high-latencies (internet range latency, 50ms+), as its quite "chatty". LBX does very little to improve latency by eliminating round-trip operations - it has "smarts" for only a very very few simple X operations (3 AIUI). In essence, LBX works for bandwidth constrained links (as does SSH), but does little for latency-challenged links - and latency is what hurts X the most, and latency is what most people do not have on internet links. (And on bandwidth constrained links, you end up with latency problems too, as you have to wait for pixmaps and other large X objects to transfer.).

IOW, LBX is pretty useless. Latency is probably where this new NX protocol has made the biggest gains.

For the problems on LBX, read it straight from the horses mouth in this paper by Keith Packard and Jim Gettys on X Window System Network Performance", LBX is discussed specifically towards the end. (Guess where I got the info for my first paragraph? :) )

Basically, LBX is crap at reducing round-trip operations. About the only real value in LBX is the compression, which is something you could also get from an SSH tunnel (and indeed SSH tunnel's can /beat/ LBX). However the real killer to X performance is latency, even if you have plenty of bandwidth, X will react very poorly in the face of high-latencies (internet range latency, 50ms+), as its quite "chatty". LBX does very little to improve latency by eliminating round-trip operations - it has "smarts" for only a very very few simple X operations (3 AIUI). In essence, LBX works for bandwidth constrained links (as does SSH), but does little for latency-challenged links - and latency is what hurts X the most, and latency is what most people do not have on internet links. (And on bandwidth constrained links, you end up with latency problems too, as you have to wait for pixmaps and other large X objects to transfer.).

IOW, LBX is pretty useless. Latency is probably where this new NX protocol has made the biggest gains.

For the problems on LBX, read it straight from the horses mouth in this paper by Keith Packard and Jim Gettys on X Window System Network Performance", LBX is discussed specifically towards the end. (Guess where I got the info for my first paragraph? :) )

Basically, LBX is crap at reducing round-trip operations. About the only real value in LBX is the compression, which is something you could also get from an SSH tunnel (and indeed SSH tunnel's can /beat/ LBX). However the real killer to X performance is latency, even if you have plenty of bandwidth, X will react very poorly in the face of high-latencies (internet range latency, 50ms+), as its quite "chatty". LBX does very little to improve latency by eliminating round-trip operations - it has "smarts" for only a very very few simple X operations (3 AIUI). In essence, LBX works for bandwidth constrained links (as does SSH), but does little for latency-challenged links - and latency is what hurts X the most, and latency is what most people do not have on internet links. (And on bandwidth constrained links, you end up with latency problems too, as you have to wait for pixmaps and other large X objects to transfer.).

IOW, LBX is pretty useless. Latency is probably where this new NX protocol has made the biggest gains.

For the problems on LBX, read it straight from the horses mouth in this paper by Keith Packard and Jim Gettys on X Window System Network Performance", LBX is discussed specifically towards the end. (Guess where I got the info for my first paragraph? :) )

Keith seems to believe that the solution to X performance issues lies in the clients; and in the long run this may very well be true. However, NX takes the old proxy/agent paradigm pioneered by LBX and dxpc and does something useful with it finally.

Keith Packard's midiplay may do the right thing if you can figure out how to obtain and build it. I don't recall. I know it displays lyrics.

Well it goes back even further than that. KeithP got his wings clipped for a patch he applied right before a feature fix. He may have choosen to "revolt" based on being insulted about being punished, over issues he'd been discussion for a long time. Like most of these splits there is probably a mixture of:

-- genuine differences of opinion regarding direction
-- unclear leadership
-- poor interpersonal issue resolution

In any case if you look at his resume this guy is the kind of guy who should be on an X core team.

So I don't see whether Keith lied or not to be a key issue. His technical issues should stand on there own entirely seperate from whether his tecnique was driven more by anger/hurt or frustration.

See this link instead.

how about www.keithp.com

It can be seen here - http://keithp.com.

Let me break down your arguments.

one is introducing an inferior GUI layer on top of a state-of-the-art one in order to run legacy applications

X11 is not a GUI, it's a device-independent, network-transparent way to draw stuff on screens.

One of the reasons Quartz was designed around display postscript was to enable possible "remote desktop" type applications for Mac; otherwise, they would have just stuck to the usual bitmap based methods.

One common misconception about X11 is that it's tied to the rendering model. It's not. The designers of X11 knew that the wire protocol could survive time, but that the rendering method couldn't. They designed the protocol acordingly. It so happens that the original rendering method was good enough for a long time. Nowadays it's getting outdated, but there are efforts to create new ones. See Keith Packard's work.

Also, have you ever even LOOKED into the X11 source? Some real shitty stuff, man.

There's no such thing as the X11 source. X11 is a protocol, like HTTP or FTP. Xfree86 (which I assume you meant) is one of it's implementations, but not the only one. I haven't looked at the code for Xfree86 yet but it used to suck a hole lot more in the 3.x days.

To wrap this up and to awnser all your inflated comments on how MacOSX stuff is so much better and X11 a pile of crap, I'd like to say that X11 has survived the test of time, Quartz hasn't. Considering that Next's similar technology didn't take over X11 I'd say X11 is here to stay.

As many of the responses to your post illustrate, folks just don't get the idea that XFree86 is a highly modular system. They don't get the idea that the fastest path to a high-quality GUI desktop for their favorite OS is to start with the existing XFree86 server, extend it as necessary, and layer atop it with a decent client side. Yes, Xlib's time has come and gone, and Xt has always been pretty hopeless. So use something like XCB as a base, and design the GUI API of your dreams atop it.

Also note that many of the XFree86 features you mention are either brand-new or not-quite-there-yet. For example, decent font support has only been solid for about a year now, and is still evolving a bit. Server-side affine transformations have been specified but not yet implemented. The spec for proper anti-aliasing of polygons was just finalized last week: it was implemented this week. (That's how fast XFree86 is moving these days with Keith Packard working on it full time. Keith has repeatedly demonstrated that it's pretty easy to add the "missing" functionality you want as an X extension.) As folks get used to the Render and FontConfig APIs, I expect to see correspondingly less interest in building window systems from scratch.

IMHO, the "visceral dislike" comes from several factors, including outdated ideas about what X is and how well it works (the performance claims I see around here sometimes crack me up), insufficient appreciation of the difficulty of what X does, and NIH syndrome.

The good news is that all the carping isn't slowing down the clueful folks any. KDE 3 is nice enough that for the first time since the mid-80s I'm not running twm as my window manager any more. I expect things to only get better from here.

Try Porter and Duff's paper published in 1984 introducing image composition that started it all!!!!

1. Get X 4.0.2 source or the snapshot. 4.0.2 has the rendering extention necessary for AA'ed and RGB decimated fonts. Also get all the other software - KDE 2.1, Qt 2.3.0, etc. You get the picture. Also, you MUST get Freetype 2.0 source!

2. Build Freetype2. There's a little hack you must do here on some systems for X to compile properly. In your /usr/local/include/freetype2 directory (which is the default location for Ft2's headers), symlink ft2build.h to freetype/config/ft2build.h. This many not be necessary on all systems... it was for me. Minor problem.

3. THIS IS THE MOST IMPORTANT (HARD) PART! X configures itself rather stupidly in most cases as far as we have seen. hosts.def overrides all these annoying settings and lets you tweak precisely for your needs... so, let's make sure it does it right. Create a new config/cf/hosts.def file in your XFree86 source directory (commonly /usr/src/xc) - note that commented out items are detected at compile time specifically for your platform:

#define DebuggableLibraries NO
#define SharedLibXdmGreet YES
#define LinkGLToUsrInclude YES
#define LinkGLToUsrLib YES
#define SharedLibFont YES
#define SharedLibXft YES
#define SharedLibXrender YES
#define HasZlib YES
/*#define SharedLibGlu NO*/
/*#define NormalLibGlu NO*/
/*#define FSUseSyslog YES */
/*#define HasKatmaiSupport NO */
#define HasAgpGart YES
#define HasMMXSupport YES
#define Has3DNowSupport YES
#define BuildGLULibrary YES
#define BuildXF86DRM YES
/* Tweak for your system or remove altogether.*/
#define DefaultGcc2i386Opt -O2 -fno-strength-reduce -mpentiumpro
#define JoystickSupport NO /* this appears to be broken */
#define XF86XAA YES
#define BuildFontServer YES
#define BuildFreeType YES
#define BuildXTrueType YES
#define BuildGlxExt YES
/*#define BuildDebug NO */
/*#define BuildXF86DRI NO*/
/*#define BuildXF86DRIDriverSupport NO*/
# define BuildRender YES
# define BuildGLXLibrary YES
# define BuildXvLibrary YES
# define BuildXF86DGALibrary YES
# define BuildXF86DGA YES
# define BuildXvExt YES
# define UsbMouseSupport NO /* this seems to be broken too */
/* Use this if we're going to use external Freetype2 libs instead..*/
#define Freetype2Dir /usr/local

4. Build X using a make World and make install (you can make logs of course if you want). You may have some problems... they're usually pretty easy to iron out - and I won't go into how here. Make sure you back up your existing X11 binary tree.

5. Configure X... do the whole thing. Try starting X with the bare basics. (Duh-step. :-)

6. If X is working, download this file...
http://keithp.com/~keithp/fonts/truetype.tar.gz
...and extract it in /usr/X11R6/lib/X11/fonts

7. Download this file...
http://keithp.com/~keithp/fonts/XftConfig
...edit it and copy it to /usr/X11R6/lib/X11

8. Start X again... this time, try to open an Xterm with the command:
xterm -fa courier
If the font is AA'ed... then BINGO! It works!

9. If you succeeded at 8, build Qt 2.3.0 and KDE 2.1 as you normally would. Read the docs. And there you go! Have fun! AA'ed fonts. :-)

1. Get X 4.0.2 source or the snapshot. 4.0.2 has the rendering extention necessary for AA'ed and RGB decimated fonts. Also get all the other software - KDE 2.1, Qt 2.3.0, etc. You get the picture. Also, you MUST get Freetype 2.0 source!

2. Build Freetype2. There's a little hack you must do here on some systems for X to compile properly. In your /usr/local/include/freetype2 directory (which is the default location for Ft2's headers), symlink ft2build.h to freetype/config/ft2build.h. This many not be necessary on all systems... it was for me. Minor problem.

3. THIS IS THE MOST IMPORTANT (HARD) PART! X configures itself rather stupidly in most cases as far as we have seen. hosts.def overrides all these annoying settings and lets you tweak precisely for your needs... so, let's make sure it does it right. Create a new config/cf/hosts.def file in your XFree86 source directory (commonly /usr/src/xc) - note that commented out items are detected at compile time specifically for your platform:

#define DebuggableLibraries NO
#define SharedLibXdmGreet YES
#define LinkGLToUsrInclude YES
#define LinkGLToUsrLib YES
#define SharedLibFont YES
#define SharedLibXft YES
#define SharedLibXrender YES
#define HasZlib YES
/*#define SharedLibGlu NO*/
/*#define NormalLibGlu NO*/
/*#define FSUseSyslog YES */
/*#define HasKatmaiSupport NO */
#define HasAgpGart YES
#define HasMMXSupport YES
#define Has3DNowSupport YES
#define BuildGLULibrary YES
#define BuildXF86DRM YES
/* Tweak for your system or remove altogether.*/
#define DefaultGcc2i386Opt -O2 -fno-strength-reduce -mpentiumpro
#define JoystickSupport NO /* this appears to be broken */
#define XF86XAA YES
#define BuildFontServer YES
#define BuildFreeType YES
#define BuildXTrueType YES
#define BuildGlxExt YES
/*#define BuildDebug NO */
/*#define BuildXF86DRI NO*/
/*#define BuildXF86DRIDriverSupport NO*/
# define BuildRender YES
# define BuildGLXLibrary YES
# define BuildXvLibrary YES
# define BuildXF86DGALibrary YES
# define BuildXF86DGA YES
# define BuildXvExt YES
# define UsbMouseSupport NO /* this seems to be broken too */
/* Use this if we're going to use external Freetype2 libs instead..*/
#define Freetype2Dir /usr/local

4. Build X using a make World and make install (you can make logs of course if you want). You may have some problems... they're usually pretty easy to iron out - and I won't go into how here. Make sure you back up your existing X11 binary tree.

5. Configure X... do the whole thing. Try starting X with the bare basics. (Duh-step. :-)

6. If X is working, download this file...
http://keithp.com/~keithp/fonts/truetype.tar.gz
...and extract it in /usr/X11R6/lib/X11/fonts

7. Download this file...
http://keithp.com/~keithp/fonts/XftConfig
...edit it and copy it to /usr/X11R6/lib/X11

8. Start X again... this time, try to open an Xterm with the command:
xterm -fa courier
If the font is AA'ed... then BINGO! It works!

9. If you succeeded at 8, build Qt 2.3.0 and KDE 2.1 as you normally would. Read the docs. And there you go! Have fun! AA'ed fonts. :-)

For those wanting to play with AA fonts in KDE make sure you grab the truetype font package from here: http://keithp.com/~keithp/fonts/truetype.tar.gz

Without that font pack all my truetype fonts where bold when => 8 point size. Yes I did setup all the font.scale/alias crap... Probably occurred because I was missing the Xft* doc in the font archive mentioned above (not the config, a file that goes in the font dir).

This was all with the "nvidia" X server so perhaps the problem is there and not Qt/KDE...

Every post CmdrTaco does about KDE is riddled with excuses ("Most of what is there is already being done within efm...", "Of course this stuff is really only with icons and images, and not fonts...").

Well lookie here!.

--