IanG on Tap

I've noticed in the last month or so that lots of people seem to have been plagued by comment spam to the point where they either switch blog comments off, or at least put them into moderation mode. So in some ways, I'm quite glad I've not got around to adding comment support here. However, it does mean that it sometimes takes me an age to discover when someone replies to what I said. For example, someone called H_A_S_H posted a response to my comments on James Gosling's paper on Window System Design. I only subscribed to H_A_S_H's blog recently, so I hadn't seen this response before. H_A_S_H doesn't seem to have comments either, but he apparently reads my blog, so I'm replying here. Hello!

H_A_S_H complains:

"Not sure I see the connection that what JG was proposing was DirectX. DirectX has not concept or design to be a window server. "

I agree that DirectX is not a complete window system solution, and I'm well aware that it wasn't designed to be. That doesn't alter the fact that given what Gosling actually wrote, my original statement here was, I believe, accurate:

"what he describes sounds pretty much like DirectX"

The "connection" is that Gosling described a graphics system, the defining feature of which sounded a lot like DirectX... He also very roughly outlined a few other bits and pieces to plug the gaps, but none of those were innovative or very interesting. The key distinguishing feature of what he proposed was that there should be very little between applications and the hardware. That's also the distinguishing feature of DirectX.

H_A_S_H then said:

"Anyone who knows what a window server needs to do would recognize that DirectX is not it"

So I think H_A_S_H is agreeing with me here, because that's pretty much what I was thinking when I wrote:

"I'm not sure that this constitutes a 'window system.'"

My version is more understated, but I'm British, so what do you expect? :-) Moreover, about a third of what I wrote was about desktop-level composition, so I don't think I can be accused of having missed the point that you need something higher-level than DirectX to tie it all together. (And yes, I ignored event routing, but I was only really interested in the graphical aspect in this particular blog entry.)

Certainly I agree with H_A_S_H's contention that DirectX is not a complete window server, and I also stand by my statement that DirectX on its own doesn't constitute a window system. Indeed, I can't find any meaningful difference between H_A_S_H's and my statements, so I think we are in agreement here. However, I'm not quite sure - if you just read H_A_S_H's blog entry without reading mine, I think you'd come away with the impression that he disagreed with everything I said. Although perhaps I'm just misinterpreting the tone.

H_A_S_H goes on to say:

"If Microsoft and JG are in agreement that DirectX represents such a widnow system, why is Longhorn introducing a Destop Composition Engine (just a fancy name for a window server)."

This looks like a straw man - I think it's pretty clear that neither Microsoft nor James Gosling are proposing any such thing.

Moreover, DCE is not in fact a window server. It's a composition engine. A composition engine is of no use if there's nothing to compose, so the DCE is clearly not the whole solution. It's not the whole solution for pretty much the same reason that DirectX isn't the whole solution - neither is sufficient on its own. (I'd like to avoid the temptation to make a crack about how anyone who knows what a window server needs to do would recognize that a composition engine is not it, but I just don't have that kind of self restraint.) Moreover, it's self-evident that DCE is not a whole window server from the fact that both Avalon and DirectX are quite capable of functioning without the DCE, but as far as I know the DCE doesn't do anything useful without Avalon and DirectX. So the DCE is clearly not "just a fancy name for a window server."

Obviously you need some kind of desktop-level composition, and I don't think I or anyone else ever claimed otherwise. Indeed, the main reason I wrote the entry was to talk about the challenges posed by the need for desktop level composition. Without desktop-level composition you'd be stuck with One Big Window. And while DirectX supports One Big Window mode (most games use it) it also supports in-window use. So today, DirectX just uses the Windows desktop composition model. Given that, it seems that Microsoft definitely don't think that DirectX is a whole window system because it relies on a desktop-level composition component today: Windows. And it will continue to depend on a desktop-level composition component in the future: the DCE (or whatever that part is called by the time Longhorn ships).

I also think that H_A_S_H misses that Gosling's proposal was aiming at a lower level. It seemed to me that Gosling was assuming that given a suitable low level API you can just built the higher-level elements of your window server support on top of that API. But what I thought was interesting, and what I was driving towards in that blog post, was the differences in philosophy for how you actually do that composition. Windows, OS X, and Gosling's proposal all take the assumption that desktop-level composition is a fundamentally different thing from any other kind of drawing - the set of tools available to you at the composition level are somewhat more primitive than are available elsewhere.

As I mentioned before, Gosling's suggested approach seems archaic for a 'future' windowing system in its lack of desktop-level transparency support, when Windows has supported desktop-level alpha blending since the turn of the millenium. Slightly before OS X came out in fact. H_A_S_H hasn't fallen into the trap that some Mac advocates do - many have an inexplicable belief that the Mac got desktop-level transparent composition first. (OS X was the first Mac OS to get this, and it shipped on 24th March 2001. Windows 2000 was the first version of Windows to support this, and it shipped on 17th February 2000. So Windows got there first by a comfortable margin.) Sadly though, H_A_S_H seemed to feel the need to aim a kick at Windows, calling the reliability of its alpha blending into question. I'm not entirely sure why he says it isn't widely used - it is used for, amongst other things, the transparent drop shadow on all menus in Windows, and I think it's safe to say that menus are pretty widely used... I'd say that it's no less dependable than the Mac in this respect. Which is not to say that it works perfectly - it did indeed have problems in the early days. But then I also take issue with H_A_S_H's claim that desktop-level transparency works just fine on the Mac - not on mine it doesn't. Am I the only person to have seen the transparent areas of the Dock go black and opaque over certain kinds of windows? I have two Macs, and they've both always done this. Indeed, this is a fine example of the point I made in my original blog: desktop composition is hard. Apple control the hardware so they don't have to contend with the considerable problems of getting things to work on thousands of different graphics cards, and even they haven't got it quite right over 3 years down the line.

Anyway, the idea that struck me as interesting was being able to use the same set of drawing technologies at the desktop composition level as you can use within an application. H_A_S_H takes issue with the idea that this might be a useful thing to do:

"I'm not convinced, while OS X is bitmap/texture based composition, very likely LH will have to cache the textures also for performance reasons."

There's a world of difference between caching textures for performance reasons and being fundamentally bitmap-based. Quartz 2D ultimately renders into a bitmap, but that's just the final output stage. Up until that point, it is a fully-vector oriented drawing system, offering scaling and rotation, and all the other goodness such a model implies. The Quartz composition model by contrast is not just using bitmaps as a performance-driven caching technique - it is fundamentally bitmap-oriented, with all the limitations that implies. (And this is exactly the model Windows has today by the way. The current 2D drawing API GDI+ (introduced in 2001) is vector-oriented and fully scalable, but the desktop level composition is all bitmap-based.)

His final paragraph is just mystifying:

"Lastly , the composition model does not impose any contstraints on the rendering capabilities. At least not on Mac OS X. Apps don't need to know what part of their window is obscured by another window. That's just old-school."

For one thing, it's a non-sequitur - the point about rendering capabilities is not connected with whether apps need to know that they are occluded. And in any case, that last point is just odd - I'm not sure why he thinks anyone was proposing that an application needs to know what part of its window is obscured by another window. Again I get the impression he's trying to suggest that OS X is superior here in some respect, but to what? Windows applications don't need to know this. (They can find out if they would like to know, but they certainly don't need to know.) Avalon doesn't require this. Even Gosling's proposal, as old-school as its composition technique was, didn't require this.

And as for whether the resolutely bitmap-oriented composition imposes constraints on rendering, try experimenting with Expose in its slow-mode, and look what happens to windows that don't move far or get resized much. (You might have to move your windows around a bit - you need to get to the point where the things are only moving a few pixels for the problem to become completely clear.) The to-the-nearest-pixel limitations inherent in a bitmap-oriented composition model become extremely obvious, as the window jogs around in one pixel increments, rather than exhibiting the smooth sub-pixel anti-aliased positioning you'd get when doing the same kind of animation at the Quartz 2D level. (Although I am famously picky about such things - maybe it's because I used to work in broadcast video engineering that I notice shortcomings most people are oblivious to.)

This illustrates that the OS X desktop composition does apparently impose constraints on rendering. (And Windows has the same problem.) So consider his parting shot:

"Desktop composition, if done right, does not impose rendering constraints"

Well quite. I hope one day to see an operating system that does desktop composition right. Neither OS X nor Windows do yet.

Just One More Thing...

While I'm replying, H_A_S_H also refers to my article on ClearType in Longhorn. His comment is pretty misleading. He says:

"Finally some decent text output in the Windows world, even though Mac OS X Panther (10.3) and maybe even Jaguar has been antialiasing and performing LCD based sub-pixel rendering already"

Let me decode the spin here a little - he strongly implies here that Windows somehow hasn't been doing this for years. In truth he couldn't be more wrong with his choice of the word "finally" there. "For over three years" would be significantly more accurate - Windows XP has had ClearType since it shipped in 2001. (And we've had basic antialiasing since NT 4.0 shipped over 8 years ago.) The point of my article wasn't that Windows is "finally" getting antialiasing and sub-pixel rendering. It's had those for years. My point was they've finally addressed one of the flaws in the rendering. (And a relatively minor flaw at that - I have several friends who swear that they really cannot tell the difference between the three examples I show. Like I said earlier, I'm pretty picky about the quality of graphics in general, and text in particular.)

H_A_S_H sets out to imply that Microsoft are somehow playing catchup here. But all you have to do is open any OS X screenshot on a Windows XP machine connected to a flat panel display so you can compare today's ClearType implementation with today's OS X text rendering. (Make sure that you've enabled ClearType on the XP box by the way - some manufacturers ship with it switched off.) When you do this, it becomes woefully obvious that Apple are the ones with a lot of catching up to do here. Longhorn just widens the gap further still by taking a technology that was already better than Apple's and making it even better.

Still, it looks like Longhorn won't actually be shipping for a long while, so with luck, Apple might have improved their own font rendering by then. I hope so - I'm all in favour of competition driving graphics technology forward.