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."
So. Who's with me to create tihs sourceforge project? Dead serious folks, not a troll. BUt who has the gumption to get it started and make it run VERY fast, then after a while see how the X.org people would think of merging or using it? Eh eh?
let me know, use my gpg key to encrypt messages (it's the wave of the future!).
--zoloto
20 years ago it might have made sense to make this very modular since nobody knew how things would end up looking. Today, let's face it, windowing is "done." All the various libraries over X look and work very similarly, just different enough to clash. Windowing is mature, I say it's time for more integration.
Modularity should be at the level of source code, not runtime components.
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...
Maybe its because Gosling is coming from X11 land and its sucky drag n drop/clipboard implementations but this is seriously a big deal is a Windowed operating system. In a Windowed Operating System, it should be easy to move data from one application to another---even though they are made by different companies. And not just text either---things like pictures as well. Going beyond this, dynamic linking and embedding is a handy feature as well.
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...
Curiously, the Mac OS X window system implements almost the exact design Jim Gosling describes in his paper.
All drawing work is done on the client side, and the window server has nothing to do with fonts, cut/paste support or much other higher level work. The window server simply assembles the drawing buffers to the displays (via hardware or software) and routes events, using hints of the foreground application and the visible window area to manage the task.
A consistent look and feel is derived by providing a consistent set of high level toolkits, residing on a set of lower level drawing frameworks.
Shared libraries make sure the needed code is readily available and resident in memory. Font are cached and vended as shared memory resources using Mach's virtual memory semantics. Drawing buffers also leverage Mach VM semantics.
Here's what happened with X11 as I see it. Fundamentally, it was a network protocol spec and client/server model. Then they built Xlib to implement the network protocol. Then, they ginned up the Athena widget set, sort of a quickie prototype on how one might actually start to build a UI on X. Having done that, they called it a day, leaving it for others to implement the look and feel, and basic functionality like cut & paste. As a result, for years most developers just used the (crappy) Athena widgets as-is, while some others started off in several directions making something worth using (e.g. Motif). Finally a decade or two later we have some decent Windowing toolkits built on X, and a look-and-feel morass.
X was overly focused on the juicy technical aspects of the day (like networking) and stopped short of providing an application-ready windowing system.
Instead, focus on delivering 1) a rock-solid, high quality API and 2) a great-looking, high performance implementation for the common case - an app running locally on a PC.
In other words, pick good API (e.g. GTK) and implement it over a small, relatively primitive rendering library to access hardware (e.g. OpenGL).
If people want to come along later and re-implement the API to insert a network transport layer, fine. They can write a shared object to do that, and slip it in place of the local version. Its backend might be VNC, X, whatever.
If they want to re-implement it to look different, or have different functionality, fine. But there probably won't be a lot of motivation to do this (except maybe to default to a different skin, or make this year's buttons round instead of square, so people feel better about paying for an OS upgrade). And if you replace the default shared GUI library with something else, *all* apps will link against it and hence look the same. (Unless you want to get fancy for some reason and run them with different link paths or something).
The problem is that there isn't enough RAM to preload all the applications. My PC during the day will run (and this is a typical work day) Word, Excel, Outlook, Visio, Project, Firefox, Internet Explorer, and an assortment of programs that don't concern me like virus scanners.
If all of these applications tried to preload themselves on startup then your swap would grind itself into dust and boottime would be in excess of 30 minutes.
It's false reasoning to say that Word takes only 2 seconds. It takes 2 seconds plus whatever time it added to the boot sequence. And if the first application you run isn't Word then there is a good chance that the preloaded Word will be swapped to disk anyway, making the next instance of Word take significantly longer than 2 seconds.
Take note that Mozilla also uses the preload trick. My work machine has consumed all 256MB of RAM and 450MB of swap after a fresh reboot and a login. That's 450MB of intensive swap activity that slowed down my boot sequence. If I just want to check my appointments in Outlook then why am I forced to wait for Word and Mozilla to fight over the swap? It's ludicrous.
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!
This like saying that once cars could go faster than it was safe to, no more innovation was needed.
What would happen if such a windowing system appeared would be this: the GTK+ folks, the QT folks, and some Xlib folks would port their libraries to the new system, add in a few missing things, and we'd have the same thing we have now, but faster, and easier to maintain.
It would also move importants bits out of the server, like the paste buffers and so on, into plain user space, where they could more easily be standardized. Free of the legacy swamp of X, clean designs could spring forth, and innovation could happen.
For instance, I'd love for there to be an easy to use clipboard stack, that could hold as many clips as there was diskspace, and an interface to help maintain it. Click the clip you want, second button it into place. This would make things like document editing easier, and make using the clipboard less of an annoyance.
All the technology in the world won't hide your lack of vision, talent, or understanding.
Hmmm...I recognize you from the old comp.sys.next.* usenet hierarchy. Didn't you disappear after the acquisition to go work on creating Quartz? If so, it must be fun to be a few steps ahead of Gosling. Oh, and thank you for the working implementation that I'm using right now.
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...