Slashdot Mirror
Gosling: If I Designed a Window System Today...
An anonymous reader writes "In his blog entry for the 10th August, James Gosling (finally) publishes a short paper he wrote in 2002 entitled 'Window System Design: If I had to do it over again in 2002'. His design is to make the window system do the absolute minimum and move all the work into the client."
I'd make it opaque to keep my arch nemisis, the Evil Yellow Face from entering my underground command center... though my mom alredy complains the basement is too dark.
He who laughs last is stuck in a time dilation bubble.
I think it is a good idea to separate the server and the client so each does its own stuff. This will increase modularity and compatibility quite a bit, IMCUO (in my completely uninformed opinion)
Don't waste your vote! Vote for whoever you want, unless you live in a swing state it won't matter anyways
His design is to make the window system do the absolute minimum and move all the work into the client.
2 3237&tid=201&tid=137
Wait, so you mean you wouldn't require this?
http://it.slashdot.org/article.pl?sid=04/05/04/22
As Gosling mentions, X is moving in this direction today. In a year or two, when the newest X changes are stable, the average GTK+ or Qt app will talk to the server via OpenGL. On most DRI-like setups, the route from GL to GPU looks like:
OpenGL -> userspace command buffer -> graphics memory (DMA via Direct Rendering Manager).
Text layout, fonts, etc, are all done server-side, and the only thing the "server" sees are pixmaps and GL commands.
A deep unwavering belief is a sure sign you're missing something...
People who complain about X being "bulky", "bloated" and all that are trolls. It was designed on slim hardware and designed flexibly.
The real test is to simply use it. Try Feather Linux or any of the other tiny distros out on some crufty old hardware and see for yourself. I've got a 90 MHz laptop that runs X just fine with 24MB of RAM thanks to Woody, fluxbox and other light applications. Gnome 1.4 also is snappy enough, though KDE is a little slow. X is not the problem if there is one! Feather runs even faster running testing and unstable Debian code and I suspect that two further years of going down Gosling's path is responsible. Of course newer hardware runs better and I don't have problems with things like xawtv, Xine or quake running with KDE or Window Maker on top of X.
From where I stand, I have no idea what people are talking about when they complain about X. They never say anything specific.
Friends don't help friends install M$ junk.
He's not suggesting sending over huge amounts of pixel data. If the app speaks OpenGL, you can ship over the OpenGL command stream. Since OpenGL was designed to support network rendering from day 1, this can be very efficient.
A deep unwavering belief is a sure sign you're missing something...
<objection tone="disgusted">
<body>xml is too sodding verbose for any use ever anywhere. Satan himself recoils before its horror.
</body>
</objection>
Doubtful. Stripping things out is easy. Writing new stuff that works is hard. X is already moving in the direction Gosling mentioned. Both GTK+ 2.8 and Qt 4 will support rendering via OpenGL. Once you're rendering with OpenGL, you're 90% to wher eGosling is going. At that point, the X-server (actually, the DRI), becomes mostly a manager of window contexts, and doesn't lie at all in the hot-path from application to GPU. Sure, the X servers unused features will take up some space (not too much, though, the X server is only 1.7MB on my system, much smaller than the OpenGL library!) but that's not a huge price to pay for backwards compatibility.
A deep unwavering belief is a sure sign you're missing something...
For my fellow Amigaites out there:
*sniff* That brings back memories. Sadly, my Amiga RKMs now support my monitor, but oh... this is so familiar. :-)
For the rest: the Amiga had a graphics library layer that talked directly to the hardware. On top of that was built the "Layers" library which does what Gosling is talking about. It just handled clipping lists and "stacking" without any other details. On top of this layer was built the GUI.
Also, the Amiga used a single message port to communicate with the application. You could have more msg ports, but rarely needed it. You waited politely for a message, fetched it, then acted upon it as you will. All your GUI events queued up nicely in the message port.
The bitter lessons of a veteran coder: http://bitterprogrammer.blogspot.com
In order to get good performance out of such a simple window system, applications need to be reasonably intelligent. One thing I think this entails is getting rid of immediate-mode APIs as the standard way to draw, and make retained-mode APIs the standard way to draw. To refresh your memory:
- An immediate mode API is something like GL or Cairo. The app sends drawing commands, and the engine executes them immediately. If something moves and needs to be redrawn, the app musdo all the work of redrawing the scene.
- A retained-mode API is something like EVAS. Instead of submitting drawing commands, specifies what the scene looks like in a scene graph. The canvas library does all the dirty work of redrawing scenes efficiently when things change.
The plight of X (which has very fast drawing, but often has brain-dead application redraw behavior) shows that no matter how fast your graphics API is, many application programmers (who usually aren't graphics programmers), will still make it look slow by writing apps that redraw the whole scene on even the smallest change. A good canvas API like EVAS fits very well with how most apps work. Canvas APIs are slower when scenes change quickly, but for most apps, most UI elements stay static. Where canvas APIs excel is in allowing simply-coded apps to demostrate good redraw behavior, because all drawing optimization can be done in the canvas.
Of course, for scenes which are animated and quickly-changing, apps should be able to access the underlying immediate-mode API, but this hsould be the exeception rather than the rule.
A deep unwavering belief is a sure sign you're missing something...
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.
How many fucking library dependancies do you need for a modern windowing system?
Quite a lot, and they are all pretty necessary.
I think you're understimating all the things that modern applications are required to do.
The windowing system should offer basic 2D and 3D functions, widgets (file selection boxes, drop-downs, radio buttons, checkboxes, crap like that),
What about ListViews? TreeViews? IconViews? What about internationalized text? Text-layout libraries? Image-loading libraries? Component libraries? HTML renderers? Interprocess-communications libraries? Event-notification libraries? Audio libraries? You can't "un-invent" all of these features. Few people want to go back to the bad-old days of poorly formatted text, apps that can only read BMP files, each app needing to reinvent stuff like PDF display and HTML display widgets, apps that can't talk to each other, apps that can't handle multimedia, apps that don't notice when things in the system change, etc, etc. Doing things "quick, fast, and shitty" is a lot easier than doing things "right," but you'd be stupid to want "shitty" over "right."
They simply used Toolbox calls, and any functions that were needed beyond that were not so hard to include right in the binary itself.
What the fuck do you think the toolbox was? It might not have been a shared library (it was a widget in ROM), but it *was* a library nonetheless. It was no different than Qt is, only it can't handle HTML, internationalized text, etc, etc.
A deep unwavering belief is a sure sign you're missing something...
He is mostly right.
The one problem is there though: by using lots of client side libraries with their own per-client state some efficiency is lost and startup time increases greatly.
We are already seeing this with today's gtk and kde programs that already have disastrous startup times.
[mark@silver mark]$ time xterm -e exit
real 0m0.111s
user 0m0.066s
sys 0m0.007s
[mark@silver mark]$ time gnome-terminal -e exit
Bonobo accessibility support initialized
GTK Accessibility Module initialized
Atk Accessibilty bridge initialized
real 0m0.311s
user 0m0.203s
sys 0m0.032s
[mark@silver rxvt-unicode-3.3]$ time src/rxvt -e exit
real 0m0.052s
user 0m0.004s
sys 0m0.003s
The machine is Athlon XP 2500+ 1G RAM, no swap, Fedora Core 2.
In the Mac OS X window system, there's still clip lists, but they are not visible to the application. The app just draws in it's window buffers.
The clips are needed to handle event routing, as you mention, and to take care of some subtle internal housekeeping, even when Quartz Extreme is in use. Since not all systems or graphics cards can run Quartz Extreme (there are certain specific graphics card capabilities needed) the clipping information is needed for software compositing cases.
Subtle point here. The hardware the apps have access to may not be the screen, but an off-screen surface which the graphics acceleration subsystem (such as OpenGL) can draw into. The window system takes care of getting the bits drawn in the off-screen surface onto the displays.
These surfaces can live in VRAM, or DMA addressable main memory. Lots of tricks can be done here by having the app draw at what is essentially the front end of the display processing pipeline.
Consider for example the GL buffer-as-texture path. Apps draw into a buffer, which when flushed is treated by the window system as a texture to be applied to the app window. The whole GL pipeline can be applied, scaling or warping the texture, altering the geometry the surface is to be applied to, mixing the texture with other texture sources, and so on.
The trouble with doing everything over OpenGL is that you're subjugating X11 to the video chip manufacturers. While I understand that gamers could care less about closed versus open drivers, I for one don't want to mess with proprietary drivers just to use a 2D desktop. I could be using Windows if I wanted that.
Right now the Open Source nv and ati drivers in X.org are more than adequate for normal 2D display, but they suck for OpenGL.
I'm not idly ranting about ideology, I'm talking practical problems. When I bought my new computer I put an GeForce in it because everyone said NVidia drivers were the best for FreeBSD. But NVidia never bothered update their driver for -CURRENT for six months. Six freaking months! I should be the one deciding what branch, OS and kernel to use, and *not* NVidia.
I fully understand that NVidia and ATI have proprietary intellectual property tied up in their drivers, and can't open them. But that's their problem, not mine. I'm not going to cry for them, because I don't have this problem with my ethernet card, hard drives or CPU.
Don't blame me, I didn't vote for either of them!
Letting the app take care of its own window borders is a bad idea as well. This is one of the worst parts in M$ Windows - once an app hangs, there is no way of closing or minimizing a window or simply of getting it out of the way. It's way better to have this handled by a separate process.
open (SIG, "</dev/zero"); $sig = <SIG>; close SIG;
However, I'd suggest talking to various people in the industry first - people tend to get lots of misinformation that sounds correct but actually isn't by reading random stuff on the web (and slashdot). See the remarks about Office preloading above - doesn't happen.
So the design of X it turns out isn't actually a serious bottleneck on performance. If you do profiling runs and such, you find that having everything co-ordinated by the X server isn't a serious speed problem and that much larger issues are things like having to read from the fb to do XRENDER blending (or was last time I checked).
Basically, before going "wow yeah, right on!" I suggest you do a lot of research into the design of past and present windowing systems - what sounds intuitively right often isn't.
DGA is Direct Graphics Access. It allows a client to directly access the framebuffer. The client needs to handle all the pixel packing models (eg, RGB555, RGB888, RGBA8888) and work out the line strides and so on.
MIT-SHM is MIT Shared Memory. Though the magic of shared memory, the client and server share a piece of memory containing an XImage or a Pixmap. The client can change the contents and then tell the server to render the image/pixmap to screen.
DRI is the most complicated of the bunch. It stands for Direct Rendering Infrastructure. The basic explanation is that it allows a client to send commands directly to the video card. At the moment the only DRI implementation is OpenGL. So for example, quake3 links to libGL.so which is a DRI aware library. The library finds out which video card you have and loads the appropriate video card driver. This driver knows how to turn OpenGL commands into the hardware commands for your video card. These commands are shoved into a buffer which is provided by DRM (the DRI kernel module) and then blasted off to the video card. X only gets involved to setup cliplists and create windows; the actual 3D rendering is all done from the client directly to the hardware.
Those 3 extensions take care of the biggest bottlenecks in X: framebuffer access, image transfers, and 3D streams. There are some other issues with the X pipe - things like latency moreso than throughput - but I'm not sure that removing the X pipe would solve those problems. The biggest issues with X on Linux right now are things like latency, single-threading, libraries that block, lack of double buffering, lack of synchronisation between window managers and widgets and clients, etc.