Live data from Hacker News

Why Apple didn't use X for the window system

developers.slashdot.org

11–20 of 37 posts

Re: Why Apple didn't use X for the window system

#11
post #2

1) Extend font server and services to vend outlines and antialiased masks, support more font types, handle font subsetting. It does that. See Cairo/XRender. or XFT. or any of the other client-side font stuff (available since 2000) 2) Extend drawing primitives to include PS-like path operations. It does that. See Cairo/XRender. Cairo was explicitly designed around a postscript-style drawing model. 3) Add dithering and…

> Unix domain sockets are fast. really fast. as in, beating shared memory sometimes fast.

Not sure where you got this but it's wrong.

Re: Why Apple didn't use X for the window system

#12
post #2

1) Extend font server and services to vend outlines and antialiased masks, support more font types, handle font subsetting. It does that. See Cairo/XRender. or XFT. or any of the other client-side font stuff (available since 2000) 2) Extend drawing primitives to include PS-like path operations. It does that. See Cairo/XRender. Cairo was explicitly designed around a postscript-style drawing model. 3) Add dithering and…

Is this a gimmick post to prove that block quotes lower the quality of discussion?

[deleted]

Re: Why Apple didn't use X for the window system

#13
post #9

Earlier quoted context omitted.

I cannot possibly upmod this enough. I just don't read posts like the one above. My brain literally refuses to bother anymore -- it scans the first couple of lines, sees the stuff it's already read, sees the repeated lines , and then starts looking around for something else to do. The author's actual intelligence couldn't be better disguised if it came in the shape of a banner ad.

To be quite honest, I find that format easier to read (well, why else would I have posted it that way?) A short snippet that is being responded to puts the text in context, allowing the reader to see exactly what I'm going on about, without reading the article over and over, matching up what part, exactly, I'm responding to. Sure, massive copy-and-paste is a waste of time, and obscures the post. However a lack of con…

Your repeated lines... aren't repeating anymore, presumably thanks to the magic of editing. That is a remarkable improvement. The sight of the same sentence being echoed over and over, a sight which practically screams "enraged fanboy", is now absent.

My other problem with the point-by-point rebuttal is that all the chaff (in the form of those detailed but disconnected footnotes) threatens to obscure the bottom line, which in this case is "it isn't 2003 anymore and X has actually made a lot of progress since then". Basically, what I wanted to read was your second post. Which is much better than the first because it's written in prose -- connected sentences that speak in your voice and tell a story -- and not in chopped-up bullet points.

Now, if this were a detailed design review of a windowing-system project, things would be different, and I'd agree with you that your format is just fine.

Perhaps the issue here is that you obviously know and care a great deal about the design details of windowing systems, whereas I would rather read a short, colloquial summary of the state of play and then go to bed. ;)

Re: Why Apple didn't use X for the window system

#14
post #2

1) Extend font server and services to vend outlines and antialiased masks, support more font types, handle font subsetting. It does that. See Cairo/XRender. or XFT. or any of the other client-side font stuff (available since 2000) 2) Extend drawing primitives to include PS-like path operations. It does that. See Cairo/XRender. Cairo was explicitly designed around a postscript-style drawing model. 3) Add dithering and…

>So why did they do their own window system from scratch? Well, because they didn't. They merely extended NeXT's disply postscript, which they already owned and had code for. Perhaps they also wanted as much control as possible. Whilst they have done benevolent forks before (webKit) perhaps they thought that with X it would be unlikely to be taken well if they "had their way with it".

What they wanted was to have the same display code driving both screen and printer. Literal WYSIWYG. X doesn't (and can't ever) work like that. Which is not a knock on X, it's just the reality that Apple have their own priorities which are not necessarily the same as the traditional Unix world.

Re: Why Apple didn't use X for the window system

#15
post #14

Earlier quoted context omitted.

>So why did they do their own window system from scratch? Well, because they didn't. They merely extended NeXT's disply postscript, which they already owned and had code for. Perhaps they also wanted as much control as possible. Whilst they have done benevolent forks before (webKit) perhaps they thought that with X it would be unlikely to be taken well if they "had their way with it".

What they wanted was to have the same display code driving both screen and printer. Literal WYSIWYG. X doesn't (and can't ever) work like that. Which is not a knock on X, it's just the reality that Apple have their own priorities which are not necessarily the same as the traditional Unix world.

Actually that makes more sense.

It also makes sense with their view on antialiasing fonts (eg look at iphone DPI, it is close to print DPI).

Re: Why Apple didn't use X for the window system

#16
post #2

1) Extend font server and services to vend outlines and antialiased masks, support more font types, handle font subsetting. It does that. See Cairo/XRender. or XFT. or any of the other client-side font stuff (available since 2000) 2) Extend drawing primitives to include PS-like path operations. It does that. See Cairo/XRender. Cairo was explicitly designed around a postscript-style drawing model. 3) Add dithering and…

> Unix domain sockets are fast. really fast. as in, beating shared memory sometimes fast. Not sure where you got this but it's wrong.

It's a little apples-to-oranges, but it's not "wrong". Lots of IPC problems really are solved fastest using a socket or pipe. Writing to a shared memory buffer doesn't clue the kernel in to the fact that there is new data available, which means you need a syscall anyway to transfer control. And it makes the application responsible for all the buffering that occurs, and applications don't have a "big picture" available to properly optimize things.

Don't diss the pipe. It doesn't do everything, but if you're going to pick just one IPC mechanism, it's the one.

Re: Why Apple didn't use X for the window system

#17
post #14

Earlier quoted context omitted.

>So why did they do their own window system from scratch? Well, because they didn't. They merely extended NeXT's disply postscript, which they already owned and had code for. Perhaps they also wanted as much control as possible. Whilst they have done benevolent forks before (webKit) perhaps they thought that with X it would be unlikely to be taken well if they "had their way with it".

What they wanted was to have the same display code driving both screen and printer. Literal WYSIWYG. X doesn't (and can't ever) work like that. Which is not a knock on X, it's just the reality that Apple have their own priorities which are not necessarily the same as the traditional Unix world.

Cairo can, and does work that way. There are current cairo backends for X11, Postscript, PDF, flat image buffers, OpenGL, SVG, win32, quartz, and no doubt a bunch of others I'm forgetting. The whole point of the thing was to have a robust, path-based imaging model that works everywhere.

This is now 4 year old technology. Please flame with more current criticism. :)

Re: Why Apple didn't use X for the window system

#18
post #17
post #14

Earlier quoted context omitted.

What they wanted was to have the same display code driving both screen and printer. Literal WYSIWYG. X doesn't (and can't ever) work like that. Which is not a knock on X, it's just the reality that Apple have their own priorities which are not necessarily the same as the traditional Unix world.

Cairo can, and does work that way. There are current cairo backends for X11, Postscript, PDF, flat image buffers, OpenGL, SVG, win32, quartz, and no doubt a bunch of others I'm forgetting. The whole point of the thing was to have a robust, path-based imaging model that works everywhere. This is now 4 year old technology. Please flame with more current criticism. :)

You could always take an X screenshot and dump it to the printer :-P Cairo is more analogous to say Qt or wx than it is DPS/DPDF.

Re: Why Apple didn't use X for the window system

#19
post #18
post #17

Earlier quoted context omitted.

Cairo can, and does work that way. There are current cairo backends for X11, Postscript, PDF, flat image buffers, OpenGL, SVG, win32, quartz, and no doubt a bunch of others I'm forgetting. The whole point of the thing was to have a robust, path-based imaging model that works everywhere. This is now 4 year old technology. Please flame with more current criticism. :)

You could always take an X screenshot and dump it to the printer :-P Cairo is more analogous to say Qt or wx than it is DPS/DPDF.

Your implication seems to be that Cairo doesn't work on an accelerated backend? That's not correct. It is correct that the primitive assembly happens client side in Cairo, which I'm not sure is a misfeature. The IPC overhead of DPS was always one of its biggest problems.

Re: Why Apple didn't use X for the window system

#20
post #14

Earlier quoted context omitted.

What they wanted was to have the same display code driving both screen and printer. Literal WYSIWYG. X doesn't (and can't ever) work like that. Which is not a knock on X, it's just the reality that Apple have their own priorities which are not necessarily the same as the traditional Unix world.

Actually that makes more sense. It also makes sense with their view on antialiasing fonts (eg look at iphone DPI, it is close to print DPI).

Actually, there are other devices, like the Openmoko Neo 1973 and Neo Freerunner, which have much higher DPI screens. The iPhone has a resolution of 480x320, at 3.5", for 160dpi; the Neos have a 2.8" 640x480 resolution screen, at 280dpi. It's really nice to look at and read text on. :)
Post reply on HN