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."
Uh, I think shfted is talking about that astronomical body which some call the Daystar, although the scientific name is Sol. "Evil Yellow Face" is probably taken from the works of J.R.R. Tolkien, where there is a character named Smeagol who enters a cave to hide himself from the evil glare of the "Yellow Face."
"Never attribute to malice that which can be adequately explained by stupidity." -- Hanlon's Razor
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...
Actually, Microsoft Bob was a successful product. The reason most people cite is Bob is the ancestor for Clippy et. al. There's a better reason - for one person in particular -- the Product Manager for Microsoft Bob: Melinda (nee' French) Gates.
________________________
My TrunkMonkey can beat up your TrunkMonkey
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.
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.
No dude. They start fast because Microsoft really, really know how to optimize their software to start fast, and because that's always been a corporate priority for them. Research has shown that given two roughly equivalent apps, most people will decide on the basis of which one starts faster.
That doesn't mean they're using dirty tricks. Look into working set optimizers some time.
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.
Neither of these features is the responsibility of the windowing system. A windowing system only records events and distributes them. To the windowing system a drag and drop is a click, a mouse move, and a declick and nothing more. All the windowing system does is alert through messages, "Hey, a click happened here", "Hey, the mouse is dragging", "Hey, the mouse was declicked." The application is responsible for knowing what those events signal. The application is responsible for interpretting the results, and for converting data from source to destination.
The same is true of cut and paste. The windowing system sends only the events. An application at a higher level is responsible for actually transfering the data. The windowing system might offer facilities for locating the source of the data, or notifying the destination to pick-up the data, but the windowing system neither knows, nor should it care, what that data is.
Linking and embedding, needless to say, is also the responsibility of the application. The application has to recognize that the data transfered is an object, load the appropriate embedding library, and make the causal link between the two.
The practical upshot of the above is that one should not confuse the functions of the windowing system, which are to arbitrate access to user interface devices and screens, draw upon those arbitrated screens, and transfer events with the functions of the application. There is nothing to be gained by burdening the windowing system with the application tasks and much to be lost in terms of flexibility.
No, they really preload. It's a background process started at boot. Some versions of office display in the system tray and some versions don't. You can kill the process or prevent it from loading, and Office takes longer to load. But you also boot faster and have more free RAM when office isn't running.
However, they aren't alone in this at all. Apple Quicktime, Mozilla, Real, and dozens of other packages all try and do the same thing. Fortunatly, the trend has been away from trying to hide this from the user.
plus-good, double-plus-good
Karma whoring: to understand who the poster is, please check this previous post
of mine.
And for a one-post description of Quartz and links to Usenet posts from "mpaque", you can see this post.
Mike's post have always impressed me, hence the apparent fanboyism of those post. And the more experience I gain in this industry, the more I respect this king of professionalism in non-official communications.
Annoying, isn't it? The trick here is not to let the apps draw to the visible frame buffer, which requires all this visible region locking, but instead to have the app draw to a buffer (in off-screen VRAM or main memory, addressable by the window system). The window system is then responsible for placing the content on-screen.
So, how does that help? The app always has a place to draw, and the separate window system process always has control over moving the bits onto the display. This means that a window manager can always order the window out, or move the window aside, without the cooperation of the application. In one implementation, the draggable areas used to move the window are registered with the window manager, so the app need not even be involved in moving the window.
One of the more interesting possibilities here comes into play when the window system is implemented atop a powerful engine such as OpenGL. In this case, the window buffers can be treated as texture sources and applied using the various texture combiner paths, along with scaling, filtering, and various transforms, all applied after the application has rendered it's content..
This allows the window system to be extended in a variety of ways without changing one line of the application's code. The windows can be minimized quite literally by adjusting the transformation matrix, or by playing with transparency, without the cooperation of the application. One could transform the window contents down to icon size, and composite the content with an iconic badge, producing a minimized icon representing the window, complete with live content, without the cooperation of the application.
I can't speak about the way the preload problem is handled today but when I worked at Microsoft (10 years ago) we spent an insane amount of effort to get the apps to load faster, or more accurately, to give the apps the appearance of loading more quickly. Often at startup we would just load as little of the app we could to render the main frame and then load the actual functional code in the background.
This was prioritized over code maintainabilty, obviously some features, and even some bugs.
I really can't see this being a huge priority in open source projects since code maintainability (modularity) and the associated flexibility is such a high priority in most of them. Just look at linux bootup. You could probably speed things up significantly by not running all those sh scripts in /etc/init.d/ (or running them after the console login has appeared, giving the appearance of boot) but what developer would give up that flexibility for a little speed?