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."

Comments

If I were to design a window system today

[shfted!]

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.

Re:If I were to design a window system today

[Pfhor]

Aluminum Foil on your window.

Will keep it nice and pitch black. Trick I learned from a friend who lived in Arizona.

Re:If I were to design a window system today

[UserGoogol]

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."

Re:If I were to design a window system today

[sporktoast]

For a minute there, I thought you were talking about a different Evil Yellow Face.

Re:If I were to design a window system today

[FlutterVertigo(gmail]

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

Re:If I were to design a window system today

[Anonymous Writer]

It is dangerous though at certain times of the day if you live on busy streets with cars and your windows point towards them.

Not to mention everyone will think your growing an indoor hydroponic crop or running a crack house.

Good idea

[penguinoid]

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)

Re:Good idea

[shfted!]

On the other hand, it would waste resources. By consolidating your RAM in the server, copies of the same program could reference the same pages in memory -- a very significant savings, if you have a smart OS and your users typically run the same applications. Plus, because user activity tends to be bursting (i.e. the CPU and hard-drive sit idle most of the time), money could be saved by equiping the clients with less capable hardware, and/or performance could be beefed up for those bursts by having a high speed/capacity server (imagine having several timse the processing power of your client machine at your disposal). Granted, this latter benefit is reduced when your users run long-running, intensive tasks.

Re:Good idea

[TykeClone]

Further, more money could be saved by making the clients with simple monochrome monitors (say green in color) with VT100 keyboards.

Sounds like it's back to the future.

Re:Good idea

[Short Circuit]

I was at AutoZone today. (Er, yesterday. It's after midnight.) I asked the sales clerk what their computer system was.

He said, "It's an old piece of crap." (He works on a green dumb terminal)

I asked him if it did the job well enough...

Re:Good idea

[timeOday]

I'm afraid I disagree with the idea of a minimalist windowing system - one that leaves most everything to user level libraries. This still leaves the door wide open for applications to implement various looks, various copy/paste mechanisms, and other things that annoy people.

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.

Re:Good idea

[shfted!]

True, but in that case, the users would notice a decline in their computing experience, versus a potential (and very real) increase by centralising resources. Take another example: When you reboot a stand alone client, very rarely is the program image for say, the word processor, already in ram. Thus, when the user starts the program, he or she has to wait for the program to be loaded into RAM. Compare this to a centralised system, where another user has likely used the word processor recently, and so the program is already loaded in RAM -- making the launch take a fraction of the time for the second user. This has everything to do with making the user experience better, not worse.

Re:Good idea

[timeOday]

I don't think a windowing system should be built around networking at all.

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!

Re:Good idea

[ipfwadm]

It takes about 2 seconds for MS Word to come up on my laptop when running on batteries. When plugged in, that would presumably be a tad faster. Even if your central server can have it open in 0.1 seconds, I would bet that the network latency would make that 1.9 seconds all but go away, and 1.9 seconds isn't much of an inconvenience to me anyway. Sure, some apps take longer, but once I've started those up, they usually stay open for a long long time. Besides, we're still only talking about a few seconds of initialization time -- Visual Studio just took 4 seconds, Photoshop CS took 20. I waste more time blowing my nose.

There's a reason nobody runs client-server. Desktop systems with fast processors are just too cheap.

Re:Good idea

[be-fan]

The problem is that in any client/server architecture, you're going to need *some* sort of protocol. How else would you do it? And you can't ditch client server, because:

a) History shows that it's rarely the bottleneck (eg: fast GUIs like QNX and BeOS are client/server);
b) There is no other good place to put it --- kernel space is too dangerous.

So once you've defined the binary protocol between apps, it's a tiny step to make that network transparent while you're at it.

Re:Good idea

[be-fan]

Oh, btw. The X protocol will probably outlive Xlib. XCB aims to speak the X protocol, while fixing Xlibs shortcomings. So if we had standardized on Xlib, we couldn't have replaced it with XCB today.

Re:Good idea

[Jeremi]

m afraid I disagree with the idea of a minimalist windowing system - one that leaves most everything to user level libraries. This still leaves the door wide open for applications to implement various looks, various copy/paste mechanisms, and other things that annoy people.

So you don't want a windowing system that is flexible, because people might want to take advantage of that flexibility?

I think your reasoning is a misguided attempt to solve by technical means what is really a politicial/sociological problem. The proper solution is to have a strong set of UI guidelines and standard libraries that make it trivially easy to follow those standards, not to limit the capability of the system just because you don't trust people not to abuse it.

Re:Good idea

[ipfwadm]

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?

Your point? When I double-click on the Word icon, it takes two seconds for the window to come up. Why should I care if the app is pre-loaded or not? If it's pre-loaded on everyone's system, why should we time it as if it weren't?

And you still conveniently neglected to address the fact that I mentioned other apps, and that even in today's high-speed world, a few seconds of waiting for your app to load really isn't a big deal. Like I said, I dedicate more time to excretory bodily functions every day than I do to waiting for my software to load.

Re:Good idea

[nathanh]

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.

OK. So let's run with that idea. We still have multiple clients and one set of hardware, so we need to arbitrate the access. We also need to have a common place where the clients can share information like window clip lists. Then there are issues like drag and drop, cut and paste, etc which also require inter-client communication. And how do you solve the issue of two clients seeing the mouse button being pressed, and both assuming that the click was for them?

At one stage you realise you need to have a program, somewhere, that coordinates all of the clients. Assuming this won't be the kernel, it must be another userspace program. We call this program "the X server". And because we have all these clients in userspace, and the X server is also in userspace, they need to use some form of inter-process communication. XFree86 and X.org already use UNIX sockets; one of the fastest IPC methods available. The only thing faster would be shared memory but that's been tried before and it's more hassle than it's worth.

Now admittedly there are some situations where the clients simply need to talk directly to the hardware. For example the client needs to upload a 3D texture or render an MPEG-2 frame. For those situations it makes no sense to send that data to the X server first. So for those situations we do have solutions that bypass the X server and go directly to the hardware. These include the DRI extension, the MIT-SHM extension and the DGA extension.

Re:Good idea

[mpaque]

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.

Re:Good idea

[timeOday]

I would design the system soundly, and make it flexible underneath, but not push that as the main feature, or give people cause to reimplement right off the bat.

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).

Re:Good idea

[nathanh]

Your point? When I double-click on the Word icon, it takes two seconds for the window to come up. Why should I care if the app is pre-loaded or not? If it's pre-loaded on everyone's system, why should we time it as if it weren't?

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.

Re:Good idea

[ipfwadm]

I wasn't advocating preloading all applications. And I really didn't intend for this to degrade into a discussion of pre-loading apps. Maybe I should have thought of that before mentioning Word. Anyways, the intention was more to point out the fact that CPUs are so fast that application load time is all but negligible, and certainly not so lengthy as to make me wish I could farm it all out to a central server.

Re:Good idea

[nathanh]

Anyways, the intention was more to point out the fact that CPUs are so fast that application load time is all but negligible, and certainly not so lengthy as to make me wish I could farm it all out to a central server.

That works fine for word processors. But there are several situations where client-server GUI is the preferred solution. For example, VPN clients are often implemented as Citrix over IPSec. In scientific and academic circles it's common for the applications to run on headless mainframes and/or supercomputers. In high security environments it's sometimes impossible to run a client locally; you must run it remotely and display it locally.

And when you start to consider other issues - how much does it cost to patch and maintain 3000 Windows desktops? - it quickly becomes obvious that per-user desktops aren't the be-all and end-all.

Load times, sure, I'll agree with you that's not a big deal.

Re:Good idea

[maxpublic]

Why should I care if the app is pre-loaded or not? If it's pre-loaded on everyone's system, why should we time it as if it weren't?

It isn't, and therefore your point is irrelevent. Just because it happens to work for you that way doesn't mean it does, or needs to, work for everyone that way.

I'd prefer not to have apps load on boot unless I tell them to load on boot, thank you very much. I don't need either my RAM or swap being soaked by an app I haven't given explicit permission to load.

But then, that may be why I don't live in a Windows world.

Max

Re:Good idea

[shirai]

So you don't want a windowing system that is flexible, because people might want to take advantage of that flexibility?

I'm afraid you have it ass backwards. An integrated system allows you the *flexibility* to do whatever you want, including a uniform interface.

You can still do whatever you want with the interface ultimately but you would be encouraged to do it the consistent way. The encouragement would come from the fact that you wouldn't have to build standard features from scratch every time.

For example, Windows never stopped Photoshop from implementing their proprietary windowing subsystem for their palettes and such. But I, for one, am glad that they still use standard drop down menus, minimize/maximize buttons, etc.

Re:Good idea

[Hacksaw]

Today, let's face it, windowing is "done."

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.

Re:Good idea

[nathanh]

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.

I disagree. A properly separated model like the DRI/DRM has high speed userspace drivers and doesn't cause problems when there is a bug with the driver. The model requires a tiny kernel module called the DRM. It manages the hardware resources (eg, DMA) and queues the clients so they don't stomp on each other. The majority of the driver is written in userspace and links directly into the client application (via libGL).

Putting an entire video driver in the kernel isn't sensible. There is too much complexity and there is no actual benefit. It's actually faster with modern cards to link the driver directly to the client. The reason being that the client can fill the command buffer without context switches. If the entire video driver was in the kernel you would need two context switches per queue flush.

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.

The only cases when the network transparency causes a measurable impact is when a lot of data is being pushed from the client to the hardware. For those situations we have direct rendering in the client. For all other situations, the costs of network transparency are lost in the noise. I wouldn't be too concerned about it.

Re:Good idea

[IamTheRealMike]

I thought this urban myth had been dispelled years ago. If they're really preloaded at boot smart guy, how comes Word still starts in under 3 seconds when running on Windows emulation on Linux? How comes IE still starts faster than Firefox again, on Linux?

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.

Re:Good idea

[moonbender]

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?

Got some more information on that? I searched for it, and I found:

Microsoft Office Startup - Microsoft Office Startup preloads some .DLL files to help speed the launch of Microsoft Office. Also places icon in System Tray.

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.

Re:Good idea

[pohl]

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.

Re:Good idea

[DonGar]

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.

Re:Good idea

[The Ego]

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.

Re:Good idea

[Sivaram_Velauthapill]

I think you are going to be proven wrong... my feeling is that there is going to be some key changes in the future with 3D acceleration. I'm expecting window systems to radically change in the future when 3D features of graphics cards are used. Let's face it: we have 3D cards, which are not used for anything. Doesn't it seem plausible that the windowing system will start using the unused capabilities of modern video cards? Doesn't it also seem logical to have everything in 3D rather than 2D (which is old school)? For instance, having everything as vectors (as under 3D) would significantly improve desktop quality as it pertains to resizing windows, changing icons, chaging colours, etc. Arguably, the display may also improve significantly (things like pixellation and blurriness on some monitors/laptops won't be as bad).

So to sum up, I think there is a revolutionary elephant knocking on the doors of window systems. That elephant is none other than 3D features of modern graphics cards...

Re:Good idea

[NtroP]

There's a reason nobody runs client-server. Desktop systems with fast processors are just too cheap.

Actually, we do, and very successfully. I can get an empty Microtel workstation from Walmart for $168.00 with a 17 in monitor for another $120.00 or so. This gives me a great "thin client" for under $300.00. Sure, that's not much more savings over, say a $500.00 stand-alone desktop, but the savings (in a lab environment) comes down the line. With a standalone desktop I have to replace it in 4-5 years and probably at least add RAM in the mean time (think Longhorn will run on 128Mb well?). At, say $500.00 a pop for 30 workstations, you are looking at $15,000 to upgrade the lab (and a $500 standalone workstation won't last very long). I can put a whole new thin-client lab in for under $10,000 or upgrade an existing lab (either monitors or CPUs) for half that (though why I'd ever need to do that I don't know - maybe moving to flat-panel monitors or bigger CRTs?)

The thin clients, once in place, are good indefinitely. If I need more speed or capacity, I just upgrade the server - not a whole lab of 30 workstations. The savings continues from there. With no internal moving parts the energy consumption for the lab goes down, and the lab also stays cooler - requiring less energy again from the H/VAC system. Small savings, but with 30 labs - it adds up. On top of this, I don't ever have to touch the clients. They PXE-boot from a central Tao-tc Linux server which loads a small kernel and rdesktop on the client and then severs the connection. The client connects to a Dell rack-mount Windows 2003 Terminal server or one of our Fedora LTSP Terminal Servers, depending on our needs.

This means that, for any given lab, I have, at most, one machine to manage, install apps on, patch, secure and otherwise babysit. This saves big bucks on time, OS upgrade licenses, Patchlink licenses, Antivirus licenses, etc. that I would have needed for every computer in the lab (assuming they were Windows desktops). I also have much greater reliability: if one of the servers goes down I just change a setting on the Tao-tc box, have the lab reboot their clients, and presto, they're pointing to one of the other servers in another building and sharing it's power while I re-ghost the dead server.

We also allow our users to disconnect from their sessions instead of logging out. This means they can come back later to any of the thin-clients in the building, log in and be exactly where they left off before. This is a godsend during power outages - the servers are on UPS's, when the power comes back on, the users reconnect to their existing sessions and no work is lost, no data is corrupted.

Granted, the thin-client scenario is doesn't work for every situation - we use high-end workstations for CAD/CAM and Video Production Labs. We also use dedicated workstations for those staff who need to sync Palms or use local USB devices, etc. but for "normal" staff, classroom and lab use - it rocks!

One Dual-processor 3.2GHz server with 4Gb of RAM can serve over 100 clients running Office at blazing speeds. Word and Exel load "instantly". You should see the look on peoples faces when I show them an empty IBM 300PL (P2 133 MHz) system net-booted to windows, and I click on Word. It invariably blows their workstations away. And because people using the Terminal Server can't install every shiny, blinky piece of software that shows up it STAYS fast. And saves me more money and headaches in the process.

The best part is that our our Mac OS X users can use RDP to connect to the terminal servers too - allowing them to use the Windows-only software with ease - instead of forcing them to give up their Macs. In fact we just did a week-long class on some proprietary Windows-only app in our iMac Lab. With the 3-button scroll-mice plugged in, they never even knew the difference; worked, like a charm.

So, yeah, you aren't going to use thin-clients for gaming and surely not at home, but in a controlled corporate or school environment, you can't beat it for ease of management, performance and cost savings.

Re:Good idea

[gnuman99]

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.

Common case for X? Local PC? WTF are you talking about. X was designed for UNIX servers during the days when "Local PC" didn't even exist. I'm *very* glad that X is such a flexible and bullshit-free protocol. That's why you can have different desktop environments be it KDE, Gnome or even stuff like blackbox.

I had yet to crash X by passing some null value or whatever to the Server. Windows API, on the other hand, "solid" as you imply, craps out when you start passing NULLs to it. Heck, you can still crash the entire box by passing some weird numbers to the right functions!

Sorry, I'll take the simplicity and flexibility of the protocol over any copy&paste or drag&drop "standard".

Re:Good idea

[shfted!]

Right. There's absolutely nothing wrong with, say, sending OpenGL down the wire and have the client's graphics system render it. :)

Re:Good idea

[wormbin]

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?

Re:Good idea

[Bloater]

Are you proposing that the windowing system should not provide straightforward access to plain drawable windows unless it also provides an easier to use interface for a widget set?

I'm not suggesting limiting functionality -- of course it should be _possible_ for applications to directly draw on their windows if they want to. Any function that is unique to an individual application should be performed this way.

But any common functions should be implemented as part of a standard widget set.

oes that mean that the windowing part of the project *must* *not* be released for testing before the widget part?

No. In fact, it would likely be impossible to develop the widget implementations before the window management side was complete.

As soon as you have a window system, people can start creating multiple widget sets that have a different programming API, different lines drawn between similar widgets (eg, combo/list/text boxes), and different look and feel. And since there are tens of widget sets already available and Open Source, any new window system is likely to have them ported very quickly to get applications ported over. So you immediately have the polydigm problem.

If GTK+ included an X server, would that satisfy your requirements so that QT developers "specifically override [your] choices".

Probably not. I'll admit I don't know much about GTK+ at a technical level, but I believe it only supports overriding the drawing mechanisms as part of its theme mechanism. What I'm proposing is an interface where the application is unaware of the specific implementation of the widget, which is chosen by the user. So, for example, I could replace multi-line edit boxes with either a vi or an emacs implementation if I so chose.

If you have a window system that can be talked to from outside it's process, there is an IPC mechanism with a protocol. You can *always* use that protocol without even having the standard widget set installed on the system. For a window system that is designed to work over the network, this is forced to be even easier to do since the protocol must be very well specified.

I suspect it would be fairly easy to modify GTK+ and QT to use the widget sets provided by the server, and once this had been done any applications using either of those toolkits would function adequately. Any other system designed for cross platform portability is likely to be portable to the new functions of the server, also.

I assume you are not familiar with computer programming. Each GTK function has a specified behaviour, it will cause a certain widget to appear with a certain relationship to other widgets, in a certain state - if the new standard widget set does not have the same available widgets (or the GTK widgets can not be described by a combination of the new widgets), or the same expressiveness of relations, and the widgets don't have at least the same states with any extra states being merely logical "substates" (for want of a better word) of the GTK states, then making GTK use the widget set from the window system will be hard. Furthermore any change in future versions of the widget set will probably screw GTK up right royal unless extreme care is taken. That means that unless you *enforce* a no GLUT/canvas policy, existing widget sets will be ported as is, with all the user interface oddities.

In short, it ain't gonna happen so start trying to persuade existing widget developers to harmonise, and application developers to hurry up and move to the new harmonised versions. *That* is the only reason there is a consistent look and feel on Windows and MAC OS. As an example, The GIMP was ported over to Windows, and it looks like a GTK application even though Windows has a standard widget set.

Re:Good idea

[Short Circuit]

He said it worked great. I think he started out trying to look "cool."

It's funny how many places still use text-based systems. Autozone is one example. Blockbuster does it too.

The latter was an interesting discovery, because the clerk preferred to type in the commands, rather than hit the shortcut keys. And she was a pretty quick typer.

Wait...

[StevenHenderson]

His design is to make the window system do the absolute minimum and move all the work into the client.

Wait, so you mean you wouldn't require this?
http://it.slashdot.org/article.pl?sid=04/05/04/222 3237&tid=201&tid=137

New windowing system from scratch?

[zoloto]

Would be a system that is both lightweight and fast. Everything could move at the speed of a finely tuned video game. Advances in rendering pipelines and library design would be easy to
accommodate. This window system design isn't particularly radical: it's more just pointing out that this is the way that X is going already, given the increasing predominance of applicationside rendering libraries. Once you accept that fact and admit that it's actually the right way to go, the design falls out, simply by
stripping away legacy stuff that isn't needed any more.

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

Re:New windowing system from scratch?

[IamTheRealMike]

Gosling basically described DirectFB so if you like this sort of idea, go hack on that.

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.

Re:New windowing system from scratch?

[electroniceric]

See the remarks about Office preloading above - doesn't happen.

I followed that thread with a lot of interest, and I believe the poster who said that MS is just really good at optimizing apps. I think the preloading "myth" may have to do with the shortcut to Office that appears in C:\Documents and Settings\Start Menu\Startup after installing Office. If this isn't a preloader for Office, what is it?

Re:New windowing system from scratch?

[IamTheRealMike]

That's (iirc) FindFast and is entirely optional. It indexes files in the background a bit like updatedb does in Linux. I don't think it preloads parts of Office, it certainly doesn't need to do that.

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:

• Disk IO. This is by far the slowest. Modern CPUs and memory are so fast relative to the disk that loading anything from disk kills your performance. Obviously you can't actually remove this bottleneck entirely but it turns out that you can significantly reduce the amount needed in order to load your app into RAM.

  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.

• OS housekeeping overhead. On Linux+OpenOffice this is the biggest bottleneck. Due to the way OO.org [ab]uses shared libraries the bulk of the time is spent inside the dynamic linker joining the bazillions of C++ shared libraries it consists of together.

  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.

• Context switches. If you have to sync to external programs during startup this can slow you down as IPC is expensive (much cheaper on linux than most operating systems but still expensive). For instance most GNOME apps sync with the X server, session manager, gconf, and some with bonobo-activation-server. That's a lot more than zero, which is how many servers (afaik) MS Word syncs with. Actually Word may talk to the RPC switch service to register in the ROT for automation purposes BUT this isn't critical to startup and can be done by a thread started after the main screen has been brought up.

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 ....

Wow comment on X

[mjh]

I think the most interesting part of the article was this:

The Result Would be a system that is both lightweight and fast. Everything could move at the speed of a finely tuned video game. Advances in rendering pipelines and library design would be easy to accommodate. This window system design isn't particularly radical: it's more just pointing out that this is the way that X is going already, given the increasing predominance of applicationside rendering libraries. Once you accept that fact and admit that it's actually the right way to go, the design falls out, simply by stripping away legacy stuff that isn't needed any more.

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?

Re:Wow comment on X

[be-fan]

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.

Re:Wow comment on X

[nathanh]

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.

Re:Wow comment on X

[Brandybuck]

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.

Lame.

[Anonymous Coward]

First, it says he wrote this article 2 years ago -- talk about a slow news day for /.

Second, isn't this more or less what X11 is doing today anyways? Yes, the xserver is getting some new extensions added to it to handle things like compositing or polygonal shapes efficiently, but a lot of the cool new features we're seeing in applications come from userspace libraries on the client side of the X11 protocol. Cool little hacks like shadows or translucent windows are just the result of rendering a window off screen and using some compositing rules on the server for generating the final image.

Cairo looks like it will make a nice DPS-like library to use for graphics (it really looks like Postscript minus any programming language features which presumably get replaced by your own choice of language) and that hits Gosling's "postscript-like" display feature.

Is this just an attempt by him to say "told you so" or something?

NON-PDF text...

[zoloto]

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

Don't remember who it was...

[Short Circuit]

But someone mentioned on Slashdot actually implemented what sounded to me like a pretty good idea. They used the structure of XML to transfer data between client and server.

It makes sense, if you think about how graphical elements are grouped and have properties...

Re:Don't remember who it was...

[Pieroxy]

It makes sense, if you think about how graphical elements are grouped and have properties...

This is probably the worst application of XML I have ever heard. And believe me, people are using it for everything and nothing already.

So your proposal is to use a protocol that takes 10x the size of the data it needs to transfer. XML (used that way) is just a file format. Why taking the most bulky one?

Talk about a fast and lightweight system. I need to draw a pixel. Size of the XML packet: 165 bytes. Wow.

Re:Don't remember who it was...

[kvigor]

<objection tone="disgusted">
<body>xml is too sodding verbose for any use ever anywhere. Satan himself recoils before its horror.
</body>
</objection>

Re:Don't remember who it was...

[julesh]

You forgot to define a schema and use namespaces to reference all your tags, as most modern XML based systems seem to do. Here's a revised version:

<?xml version="1.0" encoding="ISO-8859-1"?>
<argument:objection xmlns:argument="http://www.mynamespaceserver.com/n amespaces/argument" tone="disgusted">
<argument:body>xml is too sodding verbose for any use ever anywhere. Satan himself recoils before its horror.
</argument:body>
</argument:objection>

Re:Don't remember who it was...

[julesh]

* 897 FETCH (ENVELOPE ("Sat, 21 Aug 2004 15:39:35 +0100" "Re:Don't remember who it was..." (("Julian Hall" NIL "jules" "acris.co.uk")) (("Julian Hall" NIL "jules" "acris.co.uk")) (("Julian Hall" NIL "jules" "acris.co.uk")) (("Julian Hall" NIL "jules" "acris.co.uk")) NIL NIL NIL "") BODY[1] {32}
What, you mean like IMAP does?
)

Re:Don't remember who it was...

[FooAtWFU]

XML is verbose, yes. That's why anyone sensible uses it as a mere file format and pipes it through gzip or something when loading and saving.

Network bandwidth?

[daVinci1980]

One problem is his treatment of remote windows... He suggests sending them over as video streams.

If networking bandwidth is a problem now with the X format (which is basically just sending clicks and so forth), why does he think the response is going to be any better when sending *a huge ton of pixel data*?

Even if you assume that you only have to transmit differences, there are still cases where the difference will be several megs. (For example, a fullscreen clear in 1600x1200x32).

Re:Network bandwidth?

[be-fan]

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.

pixel pushing for remote connections?

[DataPath]

His idea of making remote connections a highly compressed pixel stream doesn't excite me - it seems less than ideal.

I would think that you would want to stream, when possible, rendering api calls, so that you can send pixel data as pixels, vector data as vectors, and 3d surface and texture data as such.

Maybe have a method for negotiating what rendering api's are supported, stream those, and then render the rest as pixels and push those.

My intuition tells me that doing so would make remote connection streaming a lot more efficient. Maybe someone with more knowledge than me can explain why this would/wouldn't be a good idea.

X is moving in this direction

[be-fan]

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.

trust your eyes, not negative comments.

[twitter]

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.

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.

What about Drag n Drop and the Clipboard???

[Brian_Ellenberger]

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.

If I had to design the app over again...

[lawpoop]

... I would choose an windowing system that did more work.

Seriously, all we are talking about is modularizing the windowing system. If the WS is as simple as possible, people are going to rely on libraries and windowing toolkits to get their work done. I guess that's already happened with GTK, etc.

Really dumb, missing the point entirely

[JessLeah]

"His design is to make the window system do the absolute minimum and move all the work into the client."

This is ridiculous. Look, ALL modern software has gotten so incredibly bloated and complex that it's just a joke. What we need is a windowing system that adopts the concept of Apple's old "toolbox"-- windowing functions and basic graphical functions AS PART OF THE CORE SYSTEM-- without the horrible kluge that I've heard "classic" Mac OS coding was. The concept was nice, though.

Look at GNOME, KDE, Windows XP. It's fucking ridiculous. How many fucking library dependancies do you need for a modern windowing system? Have you ever run 'ldd' on a modern GNOME or KDE app? It's enough to make you vomit.

It shouldn't have to be so fucking complex. The windowing system should offer basic 2D and 3D functions, widgets (file selection boxes, drop-downs, radio buttons, checkboxes, crap like that), they should be efficiently and tightly coded (preferably in C, with some ASM for speed on common architectures, and in the most CPU-intensive crap like 3D).

Look at what the Amiga was able to do with a 680x0. Sure, it had some custom chips too, but it was still a 680x0-- and modern CPUs are so fast that those extra chips are no longer necessary. With an old Mac Plus, it would take maybe a minute to boot up System 6... and with a modern Windows XP or RedShat/Fedorka box, it takes... maybe a minute. And this is progress? Also, most programs for System 6 required how many libs? Count 'em... YES, THAT'S RIGHT: ZERO! They simply used Toolbox calls, and any functions that were needed beyond that were not so hard to include right in the binary itself.

Simplicity, people. What we need is simplicity. For most tasks, a P4 running XP "feels" no faster than a '386 running Windows 3.0 in '386 Enhanced Mode did.

And that is sad...

Re:Really dumb, missing the point entirely

[Anonymous Coward]

Well, what the problem *really* is isn't so much that People Are Making Bloat, but that Bloat Is Made To Solve Certain Percieved Problems. In the older days, everyone wrote their own GUIs if they wanted them - OR they used the single included toolkits.

But now neither choice is considered applicable. We want a unified desktop that's also infinitely customizable, so that you choose a theme or default fonts or whatnot and it goes everywhere automagically.

This massive chain of desktop environment dependencies is some attempt to do everything for us. It's silly, of course.

The better solution would probably be not to integrate the "desktop look&feel" from the ground up, with unified configurations and whatnot, but to build every app from the ground up, with its OWN look and feel, using whatever kind of libraries they want to. The best apps will offer extensive customization so as to make unifying the environment a matter of having an appropriate theme for everything.

I guess there could be some amount of crossover in configuration settings, but what exists today in Gnome and KDE feels overextended. It's no wonder they're so bloated.

Re:Really dumb, missing the point entirely

[be-fan]

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.

Re:Really dumb, missing the point entirely

[mike_sucks]

JWZ once said about Mozilla bloat: "Mozilla is big because your needs are big."

People demand a lot from their desktop these days, so their desktop does a lot of things. It can take a lot of code to do it all. Sure, you may get smaller binary sizes and no library dependencies writing everything in assembly, but a) it's infeasible and b) the desktop would lack most of the features people want.

But you're missing the point. Ever done an ldd on X or an Xserver? That's what Gosling is talking about.

Using this new windowing scheme with have little/no effect on existing clients because they will still use some toolkit like GTK to do their windowing and widgets. It's not like that client developers would have to write their own widget set for each client, they will still use GTK or Qt or whatever, just like they do today.

What will need to change is the toolkits themselves.

If you had actually RTFP you would see that he was advocating a windowing system that was even more simple what you suggest.

Re:Really dumb, missing the point entirely

[TheInternet]

With an old Mac Plus, it would take maybe a minute to boot up System 6... and with a modern Windows XP or RedShat/Fedorka box, it takes... maybe a minute. And this is progress?

The question is could most the average consumer realistically replace their current machine with a Mac Plus? I believe the answer is no. Why? Because there are lot of things that weren't around in those days that we take for granted now.

Imagine trying to tell people that they can no longer use 24-bit color, watch videos, play MP3s, surf the web, render PDFs, use instant messages, compose home movies, download photos from their camera, create DVDs. Do you think it would work? :)

Obviously all this code has to go somewhere and has to be loaded at some time. And don't forget about internationalization and accessibility features.

- Scott

Re:Really dumb, missing the point entirely

[Brandybuck]

How many fucking library dependancies do you need for a modern windowing system? Have you ever run 'ldd' on a modern GNOME or KDE app? It's enough to make you vomit.

You're talking about windowing systems, not application frameworks. There's a difference. Using ldd on this currently running Konqueror process, I see the following "windowing system" dependencies: KDE, Qt and X11. That's it. And most of KDE and Qt are NOT part of the "windowing system".

Most of the libraries you see in the ldd are part of X11. Don't consider them extra dependencies just because X11 has been split. The dependency is still just one X11 package (not counting fonts).

Don't place stuff like expat, jpeg, fam, libc and the like under the "windowing system" category. And leave off the app framework libraries of KDE. They're going to be used by your application no matter what the underlying windowing system is.

if I made a windowing system...

[mcovey]

it would have a control panel, and every app would have to register with it, so it's all central (of course they can link to their part of it from tools>options or whatever. There would be one toolkit, so everything would always look the same. there would be a quicklaunch menu like on windows, where the overflow becomes a menu. There would be good support for hotkeys, drag and drop, and an overall common look and feel. I think windows comes closest to this, but the lack of the ability to theme explorer without hacks sucks, and of course it's windows. I wish someone would write an explorer clone for linux.

Re:if I made a windowing system...

[elcugo]

I wish someone would write an explorer clone for linux.

Er, have you heard about Konqueror?

Re:if I made a windowing system...

[dbIII]

it would have a control panel, and every app would have to register with it

This is impractical, and doesn't happen anywhere.

Look at MS Windows - if you go into add/remove programs you will see a few things listed. Do a find for *.exe *.com and other executable extensions. You find a few hundred more applications that are not listed there, many stand alone like ntbackup, cmd and tens or hundreds of others. Now consider a *nix system, which has the philosopy of lots of little programs that do one tiny job well. How are you going to list all of those? The best that's done is to list the commonly used things, taken to extremes with MS Windows XP where it lists recently used programs and hides the rest.

I wish someone would write an explorer clone for linux

I think the gnome people are on it - right after they do a windows registry clone and a talking paperclip.

The problem with any explorer clone is that if it looks like MS windows and sometimes acts like MS windows it will confuse when it sometimes can't act that way because the underlying system is so different - even things as trivial as people looking for a C: drive. We have to make things as usable as possible but still make it obvious to people that they are not on an MS windows system with all the assumptions that come with it (file extensions, ejecting CD's and all the rest).

Re:if I made a windowing system...

[BenjyD]

I think you're confused about what a Windowing System is. The windowing system is just the part that handles the drawing of client apps to the screen and moving them around, nothing else.

He's talking about the Amiga

[MagikSlinger]

For my fellow Amigaites out there:

I would build a "device driver" that did nothing more than manage the clipping lists and hand out graphic device ports. This might actually be best done at user level, rather than a device driver, using shared memory and semaphores.

I wouldn't use signals for anything. Everything would go through a unified message queue (along with mouse and keyboard events).

*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.

Astonishing that Gosling is getting things wrong..

[Anonymous Coward]

Since the advent of Quartz Extreme, the "clip list" should be a thing of the past. There's no application level support for clipping. There's barely Kernel support for CLipping. It's all 3-D graphics card clipping at this point. The "refresh event" should be a thing of the past by 1996, much less 2004, despite any Plan 9 patents.

Clip list for mouse events, sure. But for screen refresh? In 2004? I thought this was already a dead issue!

GMail?

[Alex Reynolds]

Gmail's interface is an interesting design, hiding away functionality until you need a specific feature.

I always wondered if a generic window system could be designed in the same modular way, with smart application modules anticipating your behaviors and adding more and more specific, functional components into the UI as you perform a particular task.

On top of that

[be-fan]

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.

RTFA?

[jbellis]

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...

Hey JC, sir, after you do the outer space thing

[2TecTom]

... could you take a wee break between engines and do an Id OpenGL GNU GUI?

Re:Quite frankly I wouldn't let him design a windo

[Knight2K]

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.

Sounds like a good idea...

[Anonymous Coward]

..But then what will I make my hat out of?

Re:Can we get a non-pdf'd link please? (no text)

[waferhead]

What, you cant run xpdf, or kpdf, or gv, or even (if all else fails of course) use the free Adobe PDF viewer?

Jackass...

Yes, but...

[Phekko]

...what do you think of a person who only does the bare minimum?

client side libraries

[CaptnMArk]

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.

Re:client side libraries

[CaptnMArk]

Exactly my point!

By running all this behavior (accessibility) independantly for all clients you have lots of overhead.

The above time is a second/cached run (w/ prelink). For the first one, it takes 4+ seconds while rxvt and xterm are still 1.

This encourages big/monolithic applications which is not the unix way.

note: rxvt I also listed has unicode support and eye candy can be enabled too. There's no need for configuration gui to run on startup.

If I had the chance...

[Madcapjack]

If I had the chance to do it, I'd call it Lindows.

Re:Astonishing that Gosling is getting things wron

[mpaque]

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.

Short-sighted design

[Dwonis]

From the article:

I would make the "window system" so minimal that it is almost non-existent. Each graphical application gets direct access to the hardware, and a window is nothing more than a clipping list and an (x,y) translation. I would build a "device driver" that did nothing more than manage the clipping lists and hand out graphic device ports. This might actually be best done at user level, rather than a device driver, using shared memory and semaphores.

The last thing we need is a new design that allows arbitrary user programs to have read/write access to the entire screen (read-only access is bad enough). Sooner or later, we are going to start running arbitrary programs on our computers in a secure sandbox environment that is enforced by the OS (and ultimately, the CPU). What happens when some cute little game your spouse downloaded yesterday decides to make itself look like your electronic banking program? Under this architecture, how do we avoid that? Hack every display driver in existence? Trust the shared library to prevent this?

Re:Short-sighted design

[mpaque]

The last thing we need is a new design that allows arbitrary user programs to have read/write access to the entire screen (read-only access is bad enough).

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.

Re:Quite frankly I wouldn't let him design a windo

[Panaflex]

I guess you never heard the NeWS have you?

Pan

Hey...

[TheDredd]

sounds a bit like describing the OSX window system, extremely minimalist, and the drawing is done on the client side

If I Designed a Window System Today...

[RAMMS EIN]

If I designed a window system today, it would have themeable standard widgets, and the protocol (function calls for local, some sort of RPC for remote) would only have to specify the widgets to be used, as opposed to all the drawing operations, which is what X11 does.

Also, it wouldn't require each and every event (mouse move, click, ...) to be communicated between server and client. Rather, clients would be able to indicate which events they wish to receive for each widget (basically like onclick, onmouseover and friends in HTML).

All this is simultaneously going to do away with the many competing and incompatible GUI toolkits for X and the non-themeability of Windows and Aqua, and make network transperency work without huge bandwidth requirements and sluggish responsiveness.

It's worth pointing out that this window system exists in the form of PicoGUI. Sadly, the site is currently down.

By the way, what is it about OpenGL that makes it so suitable for acceleration, yet it's horribly slow when implemented in software?

Re:If I Designed a Window System Today...

[imroy]

I must say I still prefer the idea of a "heavy" windowing system/manager, mainly for the benefits it gives to network transparency. For example, imagine several clients connecting from several different machines and/or user accounts. Under X11 with GTK+/QT/whatever, the different widget sets appear differently, and can appear differently depending on user settings. I like the sound of Fresco - all widgets are rendered by the server. Under this sort of system the differences between GTK+, QT, etc would simply be in API, not appearance.

I like your bringing up of HTML and the use of onclick, etc Javascript events. I'd like to take it one step further: perhaps an application or widget set could send small scripts to the windowing system to handle simple local events.

For example, the app puts up a dialog with a number of text entry boxes, buttons, and perhaps a graphic (a preview perhaps). Along with the basic widgets, it also sends to the window server a set of event handlers written in some scripting language (lisp, postscript, javascript, python...). These event handlers then control how these widgets interact without bothering the app/widget set running on the client machine. The user can fiddle with buttons and stuff, only needing actual client-server interaction when the preview needs to be updated or when the user hits the [OK] button.

So these scripts would handle the little interactions with the low-level widgets. They would allow the widgets themselves to be rather simple. The applications and/or widget sets would provide scripted event handlers to customize their exact behaviour. In this way, the set of "fixed" widgets in the windowing system could still remain flexible without becoming too complex. And like another poster said, GUI's are mostly "done" right now. Assemble the most common and unique widgets in the server, and let client-side widget sets customize them with a server-side scripting language.

windows on my world

[Doc Ruby]

I'd make the windows group by process tree, and offer frames of grouped windows, panes of subwindows, and visual pipes for STDIN/OUT/ERR among them - all embeddable among one another. I'd save window geometries in an OS DB. I'd strictly define the windowing system as merely the presentation layer, independent through an API to a logic layer, in turn independent of a data layer. And I'd write the entire windowing layer in OpenGL.

Re:windows on my world

[Jherico]

Computers are general purpose machines designed to process just about anything. Each processor design has its advantages and disadvantages in this world of generalized computing. How hardware optimization applies in this case is hard to explain, so let me take an example from another field, cryptography. The DES algorightm has several steps for encrypting a given block of text. Two of them involve an arbitrary reshuffling of bits. For instance in a given 64 bit block, bit 2 might be put in bit 5's position, while bit 5 gets put in bit 29's position and so on. Doing this in software requires a lot of steps because you can't just move a bit to its final position without saving the bit you're replacing somewhere. There are some optimizations you can do but ultimately its a lengthy operation to do this kind of thing in software. However, in hardware specialized for DES it takes virtually no time at all. That's because in hardware you can just make an input register that is crossed wired to an output register in exactly way you need. The physical design of the chip actually rearranges the numbers for you without you having to do anything at all in software.

The fact is that's there's pretty much nothing you can do in software that you can't optimize in hardware to run faster, sometimes orders of magnitude faster. But the fact is that there are far more general problems than there are specialized problems. 3D rendering and by the way, encyrption and compression, are just some of the specialized problems common enough to warrant the creation of dedicated hardware. Even then the tendency is for one or two generations of moore's law to cause generalized processors to surpass even the best hardware. 3D is still a relatively immature technology, so this hasn't happened for it yet, but give it another 10 years and you might find 3D accelerator cards are as rare as dedicated hardware encryption devices today.

Re:No thanks

[burki]

specially if it is as sexy as his last window toolkit

Re:WHAT'S WRONG WITH PDFs?

[Mycroft_VIII]

Actually I haven't seen acrobat on a windows install cd yet. I also can't recall the last motherboard drivers cd that didn't have it.
That said pdf is EVIL INCARNATE a simple 15 page document suddenly becomes a 4 meg monstrosity trying to be a 'book' in a medium where it's inapropriate. That is a pain to navigate, and you can't cut and past sections from it most of the time so you can have just the part you need in a small usuable text file.
Needless to say I equate putting docs in a pdf file on par with most of the other stuff PHB's do with tech they don't understand.
Sorry for the rant, but I just spent an hour downloading docs in 4 pdf's averaging 3 megs+ each that would have easily fit (images included) in less than a meg in any other format and been more usefull as well. The smallest was 164k, 3 pages, no images.

Mycroft

Bad idea

[haraldm]

This concept kills the concept of thin clients and X terminals - that are way more in widespread use than most people think.

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.

Re:Bad idea

[IrresponsibleUseOfFr]

This concept kills the concept of thin clients and X terminals

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:

I think that a more viable solution in the long run would be to replace the X protocol with a very simple pixel copying protocol that uses the user-level rendering libraries in the application to render to a local image buffer, then copies the pixels over the net in something that looks vaguely like a video stream. There are a variety of compression hacks that make this surprisingly efficient

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.

Letting the app take care of its own window borders is a bad idea as well... once an app hangs, there is no way of closing or minimizing a window or simply of getting it out of the way.

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.

Re:Bad idea

[julesh]

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.

Huh? If an app hangs in MS windows, I find clicking on the window's close button results in an "Application not responding -- do you want to kill the process?" dialog box popping up. Whereas X tends to cope really badly with hung clients, generally requiring you to use an entirely different command (e.g. "kill window" rather than "close window", although the names vary according to your window manager) to get rid of such windows.

Re:Bad idea

[Sax Maniac]

If your app doesn't respond to commands, you kill the process. I mean really, how often do you expect your applications to hang?

All the time. Let's say I do mass-scale operation in Finale that's going to take a lot of time - extracting all 25 parts from a score and grinding them all out to disk. It's going to take a few minutes, where the application window goes dead.

Sure, I could kill the process, but that wouldn't give me the desired results, would it?

It would be sure nice to be able to minimize the !@#*&$!@# window when it does this, and go do something else.

Re:Bad idea

[argent]

You render to a servers back-buffer, and transmit it over the network to the client.

Bitmap scraping. Been there, done that, got the bad rendering, latency, crummy feedback, etcetera. By making heroic efforts and badly compromising the user experience you can actually make it more network efficient than X, but you completely blow the feedback you need for end-user efficiency.

The usual scenario is that when you click on an object the application's idea of what the UI looks like is completely different from what's actually there. You can prevent that from happening in X by having the display server aware of where the objects are and delivering the events to them, but in a bitmap scraper that information never gets all the way to the display... so where in X you can dependably click on an object as soon as it appears, in a screen scraper you have to wait to make sure it's stable and not going to go away in the next update.

I've used them all, and unless you have a really fast network so you can keep the updates coming they cause too much human-computer latency to be worthwhile.

how often do you expect your applications to hang

Unless you have an infinitely fast processor every application goes through periods where it's unresponsive for a few seconds now and then, and a lot of applications can hang for half a minute or more. In Windows, you might be able to kill these windows, but you can't minimise or move them until the app comes back.

Look X11 is a baroque architecture

Indeed, and there are much better designs, but taking all the problems that X has and making them bigger isn't the direction to go... but it's the direction Gosling seems to be suggesting.

As for where we should go from here... there are a bunch of alternate window systems out there and some have come quite a long way. Look them up.

Re:Bad idea

[mpaque]

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.

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.

Re:Bad idea

[rmdir -r *]

Actually, the 'softies have fixed that. Use one of the newer NT based OS's- XP comes to mind- and you'll find that a crashed/stalled app can simply be tucked away until it crashes, or you kill it. No more of the wait-10-minutes-for-windows-to-wake-up thang you had to do for '98.

Re:Quite frankly I wouldn't let him design a windo

[fm6]

Not fair to blame Gosling for Swing. He mostly participated in actual Java development back when Java was still called Oak, and was still viewed mainly as an embedded systems language. Swing didn't appear until after Sun began its big push to sell Java as a general-purpose platform. By then, Gosling had been promoted to "Chief Scientist", a job that seems to consist mostly of giving speeches and writing papers.

Gosling on everythign and anything

[Anonymous Coward]

If I designed an $X today, it would be built with nanobots and turn the Earth's surface into a gray goo.

Later some small robotic rovers will come by and say "Holy shit it look like there used to be water on this planet!"

Consistency

[Bluelive]

To have consistent looking application you still need to do everything in the server. Adding more layers like is now happening with X and GTK or one of the other packages, is one way of doing that. And moving this to the server instead of the client makes it all abit faster because less data has to be moved long distance

Legacy

[ooze]

From the Article:

<i>Once you accept that fact and admit that
it&#146;s actually the right way to go, the design falls out, simply by
stripping away legacy stuff that isn&#146;t needed any more.</i>

This is actually the hardest thing to do. Todays Computer systems ar still mostly based on the concepts of 30 and more years ago. So many things that got hacked in into Unix and/or Windows in the last decades could be unified in the way it is accessed. Plan9 is actually a nice step in this direction.

DirectFB

[Anonymous Coward]

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.)

Re:Question

[nathanh]

My level of understanding on this is pretty low, but what differentiates DRI from SHM and DGA?

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.

Not in the windowing system

[Anonymous Coward]

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.

All the mistakes of X, made worse

[argent]

His new design duplicates the big mistake of X... putting policy in the application... and makes it worse. Why is it that people use Mac OS or Microsoft Windows? Because they have a consistent GUI, however it's implemented, that isn't subject to the whims of each applications programmer.

And it's unnecessary... most applications need a fairly limited set of graphic primitives, and where composition of those primitives is needed scripts in the window system can virtually always do the job: the limiting factors in a GUI are rendering, which would still be handled in native code, and the human. Yes, some applications need tightly coupled high performance control over their display, but this is still and for the forseeable future an exception. Even art software really doesn't need the kind of GPU-intensive performance he's shooting for. The applications that need to do their own direct rendering of complex scenes, rather than just a fast way to pump bitmaps to the display, are pretty rare and can be dealt with as they are now with a shortcut through the window system. With OpenGL you can even have multiple applications of that kind running concurrently without interfering with each other.

So the special case he's optimising for is already well handled, we don't need to build the window system around it. And in the general case it wastes the performance of the graphics card by keeping the application way off in the processor intimately involved with the mechanics of moving images around. As GPUs get more power and memory it will be more and more practical to move more of the window system into the GPU, and it will be more and more desirable to handle rendering in a common layer that's close to the display (in the GPU, where possible) the way Mac OS X already handles compositing.

Quartz Extreme is pretty crude. It shouldn't be necessary to do rendering in the processor and compositing in the GPU (the normal case, because it doesn't copy rendered windows back from the GPU to the CPU and maintains the master of each Quartz window in main memory at all times), with all the extra memory traffic that creates... but it shows the way forward. A truly 3d GUI where windows and more complex application objects are managed in 3d space the way a window system handles them in 2d space should be possible and efficient.

But consider what happens when you move a window into the 3d background... the GUI moves it away from you and tilt s it at an angle so you can keep it in view "off to one side". You can't keep going back to the application over and over again to re-render its part of the screen as your viewpoint changes. Instead you let the GPU map it onto a surface, and navigaton of the environment is smooth and more or less invisible to the application. Perhaps one might send the app a signal that say "suspend updating" when it's too far away or out of your viewpoint, but that's an optimization.

No, this is exactly the wrong time to go back to the X model of a dumb server and smart applications.

Re:All the mistakes of X, made worse

[jaoswald]

Gosling is not discussing the details of widgets, etc., which make up the (hopefully consistent) USER EXPERIENCE of a graphical user interface; instead, he's concerned with the low-level plumbing which lets multiple applications share the screen and mouse, without having to be aware that other applications have windows which might be overlapping one's own. These problems are totally different, and mostly unrelated.

The widgets that make up the GUI of each application, as well as the lowest-common-denominator graphics tasks could be provided by a single system-wide library that every application would use, to ensure consistency. Gosling is only thinking about how this library would send colored bits to the screen and get mouse clicks from the user.

Quartz doesn't enforce a single user interface, as Apple's own "interface of the year" adventures demonstrate.

Office doesn't add anything to the boot sequence

[rd_syringe]

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.

Re:Double Buffering

[julesh]

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.

Re:No

[silverfuck]

Actually, I think you'll find it is. I recently blew my system away with a really dodgy device driver, and had to reinstall, including Office 2k. Under the startup folder, it placed a shortcut with the name "Microsoft Office", which points to ""D:\Office\M$ Office\Office\OSA9.EXE" -b -l". A little Googling turns up many sites that say this is a program that precaches offcie components to speed up access times. Admittedly, they could be falling into an urban myth, but there are more of them than you, and I think I trust 9,630 websites more than one slashdot user who doesn't back up with evidence. (Sorry to flame slightly.)

Gosling, Hopkins, JCR, and Unix-Haters Perspective

[billstewart]

It's worth keeping the personalities and time frames here in perspective.

• James Gosling wrote the NeWS Network Extensible Windowing System.
• Don Hopkins was one of the absolute wizardly programmers using NeWS.
• JCR was a NeXT Weenie, and is now an Apple Weenie. (I forget if you worked directly for NeXT or only were a heavy user...)
• The Unix-Hater's Handbook was written in the late 80s, so the comments mostly relate to X11R2 or thereabouts, and when Don was referring to a 486, that was a fast computer. I thought the book was misnamed - it was largely the sendmail- vi- and emacs-hater's handbook, and many of the things that were evil about Sendmail, Vi, and Emacs then are still evil today.

So when Don was ranting about architectural choices that were wrong with X, he was comparing it to more interesting architectures like NeWS or various experimental things that have been left in the past, or to Windows which was relatively lightweight (though badly buggy) back then (the "lightweight" part has since been fixed.) And the things that he complained about mostly haven't changed a lot, except that Motif was really bloated back then, while these days Gnome looks bloated (but does a lot more) and Motif looks comparatively lightweight.

The one major difference is that today, the main uses for X are to run a browser as well as Xterm. To some extent, this balances the really big advantage of X (or NeWS) over Windows, which is being able to access resources on lots of machines at once.

What Don *didn't* rant about, because he was ranting about X, was that NeWS had its own horribly broken tradeoffs as well. The way it implemented really good WYSIWYG rendering and let applications decide which pieces of work should run on the client vs. the server was to pass executable chunks of Postscript code around for the interpreter on the NeWS Window Server to run. When everything worked, it was excellent, a joy to work with, and received the kind of raves that NeXtStEp enthusiasts give NeXt'S environment, but it had an almost total lack of security between applications, and if anything broke your screen tended to explode into an angry fruit salad. There were few people capable of doing real debugging in this environment, though Don, who was one of them. wrote an amazing debugger for it.

Java took many of the good ideas from NeWS about letting you safely hand chunks of code between cooperating interpreted processes, but did so with an actual security model built in from the beginning. There are people who don't like it (especially ObjectiveC fans), but one of its worst problems, slowness, has been fixed in part by JIT compilers and in part by Moore's Law. Unfortunately, some of Java's competitors, like ActiveX and JavaScript, didn't have a solid security model built in to them, so while they also let you divide labor between clients and servers, they're a security nightmare that could, and should, have been avoided.

Disclaimer: JCR and Don are friends of mine. I've met Gosling occasionally, but it's been a few years.

Gosling ignores the lesson of HTML.

[mburns]

Yes, I agree with you that HTML must be mentioned. It is the most successful of GUI interfaces after all. And, Gosling is defying this success. File caching and fonts are left to the browser to optimize the use of bandwidth. HTML pages are incomparably preferable to PDF transmissions. As for improvement of the X protocol, whatever happened to the X compression methods where fonts were cached instead of being resent?

The future must resist this kind of reductionism proposed by Gosling. Instead, high extensions are needed for caching and parametric transforms, and for audiovisual channels, joysticks, and other kinds of telemetry.