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."
Here it is..
Window System Design:
If I had it to do over again in 2002.
James Gosling
December 9, 2002
In the deep dark past I have been involved in building window
systems. I did the original design and implementation of both the
Andrew and NeWS window systems. Both of which predated
X11. They shared with X11 the architectural feature of being
networked: clients sent messages to the server over TCP
connections. I occasionally get asked "if you had to do it over
again, what would you do? Would you do the same thing". The
answer is a strong no. It's now 20 years later, and the
technological landscape is totally different. So here is what I
would do. But first...
The term "window system" is somewhat loose. It generally refers
to the mechanism by which applications share access to the
screen(s), keyboard and mouse. Beyond this it generally contains
facilities for inter-application messages such as support for cutand-
paste, and drag-and-drop. It also often contains support for the
decorations surrounding windows that provide the user interface
for resizing, opening and closing windows; although in some
systems this has been left up to the application. Sometimes the
window system provides higher level abstractions like menus.
When a system is designed, there are always tradeoffs made that
reflect the technology of the day. In the case of Andrew and
NeWS, these tradeoffs were based on the state of the art 15 to 20
years ago (this probably applies to X11 too, but I wasn't involved
in the design analysis behind it). There were a number of things
that were very different between then and now.
1) The most significant is the relative performance of graphics
rendering and network communication. Back then,
rendering was relatively slow. The overhead of network
communication was significantly overshadowed by the
overhead of rendering.
2) Back then, there were no shared libraries. This seems odd,
looked back at from today, but back then no version of
Unix had the ability to have a library like libc or OpenGL
that was shared between processes. All applications had to
be "statically linked". There was a primitive segment
Background
History
sharing facility that allowed one segment per process to be
shared, that was at the beginning of the address space; but it
wasn't powerful enough for this purpose.
3) Putting large things, like windowing libraries, into the
kernel is generally a bad idea. It has a significant negative
impact on the reliability and testability of the system.
4) When hardware acceleration was available, it generally had
no interlocking mechanisms for arbitrating amongst
independent threads that were trying to use it. This
generally meant that either the accelerator was permanently
allocated to a thread (very common, since acceleration was
normally 3D hardware used exclusively for CAD), or there
was an software interlock mechanism that added some cost
to each operation.
So, given these, where do you put all of the code that is involved in
the window system - including the graphics rendering library?
Remember that rendering libraries tended to be large, since
hardware acceleration was almost non-existent.
They couldn't be in each user process, since without being shared,
they would take up an unacceptable amount of RAM. So the only
way to get one copy of the code, and have it outside of the kernel,
was to have it in one process, and to have applications
communicate with this "window server".
But today, while putting large amounts of code into the kernel is
still a bad idea, rendering performance has improved dramatically,
and most operating systems have shared libraries. The increase in
rendering performance has outstripped Moore's law, which in turn
has outstripped the increase in generally available bandwidth,
making the overhead of shipping requests through the network an
unacceptable burden.
High per
Aluminum Foil on your window.
Will keep it nice and pitch black. Trick I learned from a friend who lived in Arizona.
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...
In the common case, there is no client or server, just an app running on a PC. So don't build the assumption of networking into windowing.
Look at X: it's built on a standardized network protocol. If you want you could implement a different Xlib, even one with a different API, so long as it used the X network protocol. But that extra degree of design freedom has been a complete waste of effort, code complexity, and CPU cycles. Instead of writing code to generate X protocol network messages, everybody uses XLib. In other words, people ignored the network protocol, and standardized on the Xlib API.
So let's centralize around an API, and write different implementations of that API that speak X over a network, or VNC, or whatever - but the first and most important implementation will simply and efficiently draw on the local screen!
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
he also says that (a) sending pixel data is basically what the Sun Ray product does and (b) it's about as efficient as using the X protocol would be, or (reading between the lines) they wouldn't have done it that way...
Most Linux distros come with PDF support included. Unlike Windows.
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.
You're an idiot. Gosling had almost nothing to do with Swing, which came out a while after Java had already become big. If anything, he might have had a hand in AWT.
I feel like I'm responding to a troll here, but I think you haven't used Swing in a while. The latest releases in 1.4 are significantly better looking and faster. They also make better use of the underlying graphics hardware in Java 2D. I've written apps in Swing that have been very responsive; you just have to take the time to learn the framework.
I will grant you that Swing can get complex and it can take serious effort to eliminate bottlenecks. It's intended to be a general framework for MVC based applications, so it has to cover a lot of cases that may not be applicable for all applications. You sometimes have to subclass and override default painting behavior to tailor it to your usage. But at least you have the ability to do that if you wish.
It also has a tendency to be lower-level then some other approaches. I've seen people throw together VB apps with a lot of functionality pretty quickly. It can take longer to get there in Swing, but the results generally are more maintainable and scalable.
There are efforts in the works to generate standard higher-level constructs, such as database-backed tables with sorting, that other GUI frameworks provide. Check out JDesktop Network Components to see what's in the works. There are also efforts underway to allow Swing apps to fit more neatly into the native shell (such as tray icons).
Swing was pretty deadly in the past, but it has improved significantly recently. Ironically, I'm seeing a lot more MacOS X apps written in Java or Java apps developed on MacOS since Apple has put a lot of effort into their Swing look and feel for Aqua. If you are looking to Apple for direction, I think that is a significant data point.
======
In X-Windows the client serves YOU!
What, you cant run xpdf, or kpdf, or gv, or even (if all else fails of course) use the free Adobe PDF viewer?
Jackass...
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.
sounds a bit like describing the OSX window system, extremely minimalist, and the drawing is done on the client side
You're wrong, at least in your second point.
Kernel space is only dangerous in the case of badly written graphics drivers. Windows NT has had kernel-level graphics hardware since its inception, and its only been a cause of problems with extremely buggy graphics drivers. And guess what - buggy graphics drivers are gonna cause problems whether they're in the kernel or not. Might as well put them there for the speed advantages.
Network transparency's of only marginal value, particularly considering the cost (non-kernel graphics). Anyway, there's plenty of other methods of doing network logins without needing it built into the core graphics API.
Actually, what he's describing sounds a lot like DirectFB. Take a look at : http://www.directfb.org/
It's library that interfaces the Linux kernel framebuffers and hardware acceleration directly. At the moment, supports Matrox cards best (with partial support to ATI Rage and S3 and others.) The application suite includes X11-implementation and SDL programs should run directly.
I tried it a while ago but switched back to X.org. (Switched G400 to R9200 too.. UT2004 needed more kick.)
It doesn't kill the concept of thin clients. You render to a servers back-buffer, and transmit it over the network to the client. Then you proxy mouse and keyboard events to the window on the client to the server. It is non-trivial, but definitely possible. From the article:
So, no, this type of window system does not preclude thin clients, nor kills their concept. According to an actual study done by Sun, it is actually about as efficient as X and much easier to implement.
If your app doesn't respond to commands, you kill the process. I mean really, how often do you expect your applications to hang? I don't consider it an absolute requirement to be able to kill applications right from the window decorator. In fact, I will claim the opposite: it is a bad idea to have abortive closes so easily accessable from the UI. Make an app that matches up process id's to clip-lists and make them kill from there. I don't consider this complaint particularly damning.
Look X11 is a baroque architecture. We know now what the architecture of machines look like now, and what is likely to change within the next 10 years. Gosling's proposal directly takes advantage of the way things are likely to change. X11 comes along kicking and screaming every step of the way. That said, Gosling's window system is just an idea on paper. X11 is alive and in the flesh. The only way this debate means anything is if someone goes out and implements Gosling's proposal. Then, things will get interesting. We will finally get to use some of the wisdom computer scientists have accumulated over the last 20 years since X was designed.
Facts are meaningless. You could use facts to prove anything that's even remotely true! -Homer Simpson
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.
And the fact that Office apps are mostly loaded into memory at boot, thus providing the illusion of speed when they're 'opened', hasn't been pointed out to you?
.DLL files to help speed the launch of Microsoft Office. Also places icon in System Tray.
Got some more information on that? I searched for it, and I found:
Microsoft Office Startup - Microsoft Office Startup preloads some
Apart from the fact that I've never seen this - but then, I'm using Office 2000 - preloading some DLL files is still far from being "mostly loaded at boot". Note that my winword also takes 2 seconds (I measured it) the first time I start it. Subsequent starts are instant. So, yeah, 2 seconds are not really an illusion of speed, they just are that fast. I guess.
Switch back to Slashdot's D1 system.
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.
This is actually exactly how Qt/Embedded works :)
--
(I used to be jo@trolltech.com)
Microsoft Office isn't preloaded into memory on bootup. This is yet another false Slashdot meme that gets regurgitated over and over until it becomes "fact." At most, all Office ever did was automatically run a quicklaunch bar at the top of the screen. I don't even see that around anymore.
And the fact that Office apps are mostly loaded into memory at boot, thus providing the illusion of speed when they're 'opened', hasn't been pointed out to you?
And the fact that that's not true hasn't been pointed out to you? Yet, I fully expect to see ignorant people repeat this false idea again in the next Windows discussion.
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?
From what I've heard, this is the way the next release of Windows will work -- all windows will be drawn to independent buffers in video RAM and then composited once per refresh to produce a smooth display. Options such as rotating and scaling windows will be available.
Basically Office starts really fast because it makes heavy use of lazy loading (only loads code just-in-time), and because Microsoft do things like reordering code and functions in the source to ensure that frequently used code resides in the same pages in memory.
OK, I can see from the replies to my first post some people are still sceptical.
Startup time in most desktop apps has multiple components:
Code is split into pages. When the OS (this is true of all modern operating systems, Linux and Windows alike) starts your app it doesn't read each byte from disk into memory then jump to the entry point. It maps it into memory, so when the processor accesses a piece of the code it will be faulted in from disk. This is a good optimization because it means code that is never used is never loaded. However, pages are fairly coarse grained: 4k on standard IA32 setups (you can run it in 4mb mode as well but I don't know anybody who does this). Page faults hurt performance: each time your app faults, it's suspended while the hard disk seeks to the right place on disk then you have worst case a rotation of the disk platter before you can start reading. Therefore it's possible to speed up starting time significantly by packing all the code you need to start the app and bring it to the main screen into the same pages. This can often be as trivial as moving functions around in the file (hence the comment by an ex-'softie about code maintainability and such) but more advanced tools exist to do the same sort of thing in a systematic fashion.
You can also use code compression. This is counter-intuitive (decompressing stuff is slow right?) but some simple algorithms can be very fast and CPUs are sooooo much faster than disks are that it can actually be worth doing.
This is fairly pathological behaviour for all C++ apps on Linux. Lots of string comparisons and such. OO startup was analyzed and it was performing over 1.8 million strcmps inside the linker alone.
Prelink was developed to address this case for "normal" C++ apps like KDE things, but OO unfortunately dlopens much of its code so making prelink ineffective.
A good solution to this problem for us would be to implement DT_1_GROUP support in glibc, but this involves hacking on glibc which is a nightmarish task that nobody wants to do. But this is what kills OO in the OO vs MS Word on Linux (via Wine) test.
You get the idea. You don't have to "cheat" to start fast, you just have to know what you're doing and make it a priority when coding. Unfortunately most developers aren't aware of these issues and ignore them until it's too late and you have something like OpenOffice or Eclipse ....