Whoa, I think you missed something torifile. Smircle is actually right. One reason Mac OS X's GUI is generally slower than Windows XP's *is* because Mac OS X's GUI has a lot more work to do. Do full window buffering and live multiple-layer compositing ring a bell? Of course, Quartz Extreme speeds this up a bit, but your accusation is still way off-base.
He may be, but the ULTIMATE reason for the slowness isn't in the demandingness of the GUI. It's probably not at all due to that. If the graphics routines for OS X were in the kernel, as they are in XP, I'd be willing to bet that they'd be as responsive as XP. I was focusing on where the blame for the speediness lies and not really debating the intensiveness of the GUI.
I guess the reason for my strong reaction was that people keep citing OS X's GUI intensiveness as a problem because they think it makes the system slow. I don't think this is the case and rather than being lambasted for making what some see as poor decisions (from a GUI responsiveness standpoint), I think Apple should be lauded for their commitment to stability and security at the expense of some speed.
He may be, but the ULTIMATE reason for the slowness isn't in the demandingness of the GUI. It's probably not at all due to that. If the graphics routines for OS X were in the kernel, as they are in XP, I'd be willing to bet that they'd be as responsive as XP. I was focusing on where the blame for the speediness lies and not really debating the intensiveness of the GUI.
I did refrain from posting a spicy reply, but I believe you did not even try to understand what I wrote but went along on some conditioned reflex. Which I think is not actually helping in finding the facts.
Point is, I never derided Apples decision to move to a more advanced graphics layer from the first release of MacOS X. It was a sound move and put them ahead of windows and miles ahead of Linux. But it does come with a price - semitransparent widgets and soft dropshadows ala Aqua are highly expensive. On machines without QE capable gfx chips or less than 64MB of video RAM, the CPU ends up lots of time compositing windows - a more computationally expensive job on OS X than on 9 with its opaque windows. Also, moving developers from managing their own backing store buffers (Windows, MacOS 9 and earlier) to *not* managing them (since it results in triple-buffered windows on OS X) will take some time.
I have no doubt that Longhorn will have a slower UI than XP for the same reason the UI in X is slower than in 9 - not because they will move the graphics drivers out of the kernel again.
I'm gonna still have to disagree with you, torifile.
When manipulating a window in the old graphics systems like Windows and Classic Mac OS, the system just has to push a few kilobytes and draw the contents directly to the screen (or what is called a "gworld", a temporary off-screen graphics port used before blitting the bitmap to GPU). In Mac OS X, you're pushing a few megabytes into an additional memory buffer plus performing an array of compositing and vector calculations before sending it back out to the GPU for finally printing to the screen. Even if these operations were put into the kernel, which would be pointless as it would offer practically no performance gain, the Mac OS X graphics engine is working *magnitudes* harder than its Classic cousin.
I refer you to an old ArsTechnica article published back in the Mac OS X Public Beta days:
Here's are relevant quotes that I believe sufficiently illustrate my point:
Quote:
Think about the calculations necessary to do something as simply as move a window in Mac OS X. Every pixel of that window must be re-composited with every pixel of every application in each location for each new position of the window. Imagine a 500x300 pixel window (about 24 rows of 80 column text) moved 100 pixels to the right, with 5 other application windows behind it. That's about 15 million compositing calculations, each with 30 operands (red, green, blue, and alpha values for each contributing pixel from each application), all for moving a small window a few inches.
But wait, there's more. When something changes on the screen (a window moves, appears, or disappears), pixels belonging to other applications are revealed. Those pixels must, of course, be composited before they can be displayed, and those compositing calculations need all the pixel values for each application that has a pixel in the newly revealed area. Adding the compositing calculations associated with the newly revealed screen area in the moving window example above (and accounting for the transparent drop-shadow on the window) brings the grand total to almost 17 million 20-30 operand calculations!
Quote:
But it's the memory usage that's the real killer. Classic Mac OS applications only need to retain the essential information about each window: its size, features, and contents. Mac OS X applications have to retain the same information, of course, but remember that the window server also has to retain a complete memory image of every pixel in the window! Repeat this for every single window on the screen, and it adds up very quickly.
Classic Mac OS requires only a few kilobytes to store the basic structures that define a simple, empty window. In Mac OS X, the total memory required for even a completely empty window is proportional to its size, regardless of the nature of its contents (if any).
Take a look at this window list from a typical work day on my G4. The total memory used by window buffers alone is an astounding 120MB! And remember, this is before even accounting for things like, say, the memory required by the actual applications and the core OS itself!
torifile has a point on the raw rendering speed. The routines in Win* are indeed in the kernel, much as some of the critical bits of IE's engine are. And yes, that does speed them up while vastly decreasing the stability.
To a point.
At which point Brad and Smircle's explanation kicks in and explains the rest of the speed difference.
And Longhorn will be built on .NET/C# which is a vastly more modern developer environment than Apple Cocoa/obj-C.
You *might* have a point on the *environment*, where that's defined as the IDE.
But the APIs? The language? Sorry, but ain't so. I've worked with .NET/C#, as well as Cocoa/Obj-C in various incarnations over the years (Visual Studio/C++/Java, NeXTStep), and have to disagree with you vehemently on this one.
What I've seen of the .NET APIs, cleaning up the cruft of Win32, hasn't really impressed me. *Carbon* was a better cleanup than this, and that's not saying much IMHO. (I hate Carbon programming, just for the record. And the old MacOS Toolbox was hideous.)
C# is an interesting exercise in attempting to co-opt Java into a rather intriguing CLI (where, again, MS has taken a perfectly good and universally acceptable acronym and absconded with it for their own marketing purposes...). I like the concept of the CLI, but much as how I liked the *concept* of the Registry, the implementation leaves a lot to be desired. (I mean really, recrafting goodly chunks of C++'s basic method mechanism to act in a new manner that's incompatible with other C++ code behaviours, and then saying CLI supports C++?? Classic MS.)
Frankly, C# was a really clever academic exercise that should have stayed in the ivory tower. It's neat, it's clever, and it has some good points. But it certainly isn't the end all and be all of programming languages. Only MS could pull off betting the company on something this half-baked.
And I have to report that most of us in academia, when presented with this by the MS folks, were looking at the CLI going "Yeah? So? This is supposed to be *new*?" *shrug* The MS folks couldn't figure out why we weren't signing over our firstborns to them out of gratitude and awe. (Hint: reality disconnect in Redmond.)
I'm hoping that with Xcode, we'll be catching up and surpassing in the IDE department... the extensibility of it has my widdle brain spinning with possibilities. I can't wait to see what 3rd parties come up with.
At which point Brad and Smircle's explanation kicks in and explains the rest of the speed difference.
Not gunna buy it until we see the last of the speed optimizations to the GUI that Apple comes up with. The difference between 10.0 and 10.1 and now 10.2 and soon 10.3 on the same machines is extraordinary. I'm holding fast to my argument that it's not the intensiveness of the GUI that causes these slowdowns. It's other things. And those things are getting worked out...
All technicality aside, I throughly enjoy using Mac OS X.
To me Mac OS X is like Silly Putty...it is smooth and it just feels so dynamic to me and I love how programs interact with each other...even if it is not meant to.
Every update I have seen of Windows I see Microsoft getting further and further away from this kind of experience.
Maybe with Longhorn they will finally do it right but I doubt it. At this point unless Microsoft re-writes their OS entirely from scratch I think it will just be the same OS you see today with a few gimmicks.
What so many people are missing with Mac OS X is that Quartz is not just a fancy "ohhh" and "ahhh" presentation to show who has the coolest OS but it is a truly advanced graphics engine.
I love that I can go in say OmniGraffle and take any image format readable by Preview and rotate it, add transparency, resize, and save it to PDF all on the fly. This to me is what the other guys are missing (Microsoft).
Among having a UNIX core which is another entirely awesome thing that will keep Microsoft far far behind. Not to mention, we have a huge community outside of 1 Infinity Loop that is backing us...
Comments
Originally posted by Brad
Whoa, I think you missed something torifile. Smircle is actually right. One reason Mac OS X's GUI is generally slower than Windows XP's *is* because Mac OS X's GUI has a lot more work to do. Do full window buffering and live multiple-layer compositing ring a bell? Of course, Quartz Extreme speeds this up a bit, but your accusation is still way off-base.
He may be, but the ULTIMATE reason for the slowness isn't in the demandingness of the GUI. It's probably not at all due to that. If the graphics routines for OS X were in the kernel, as they are in XP, I'd be willing to bet that they'd be as responsive as XP. I was focusing on where the blame for the speediness lies and not really debating the intensiveness of the GUI.
I guess the reason for my strong reaction was that people keep citing OS X's GUI intensiveness as a problem because they think it makes the system slow. I don't think this is the case and rather than being lambasted for making what some see as poor decisions (from a GUI responsiveness standpoint), I think Apple should be lauded for their commitment to stability and security at the expense of some speed.
Originally posted by torifile
He may be, but the ULTIMATE reason for the slowness isn't in the demandingness of the GUI. It's probably not at all due to that. If the graphics routines for OS X were in the kernel, as they are in XP, I'd be willing to bet that they'd be as responsive as XP. I was focusing on where the blame for the speediness lies and not really debating the intensiveness of the GUI.
I did refrain from posting a spicy reply, but I believe you did not even try to understand what I wrote but went along on some conditioned reflex. Which I think is not actually helping in finding the facts.
Point is, I never derided Apples decision to move to a more advanced graphics layer from the first release of MacOS X. It was a sound move and put them ahead of windows and miles ahead of Linux. But it does come with a price - semitransparent widgets and soft dropshadows ala Aqua are highly expensive. On machines without QE capable gfx chips or less than 64MB of video RAM, the CPU ends up lots of time compositing windows - a more computationally expensive job on OS X than on 9 with its opaque windows. Also, moving developers from managing their own backing store buffers (Windows, MacOS 9 and earlier) to *not* managing them (since it results in triple-buffered windows on OS X) will take some time.
I have no doubt that Longhorn will have a slower UI than XP for the same reason the UI in X is slower than in 9 - not because they will move the graphics drivers out of the kernel again.
When manipulating a window in the old graphics systems like Windows and Classic Mac OS, the system just has to push a few kilobytes and draw the contents directly to the screen (or what is called a "gworld", a temporary off-screen graphics port used before blitting the bitmap to GPU). In Mac OS X, you're pushing a few megabytes into an additional memory buffer plus performing an array of compositing and vector calculations before sending it back out to the GPU for finally printing to the screen. Even if these operations were put into the kernel, which would be pointless as it would offer practically no performance gain, the Mac OS X graphics engine is working *magnitudes* harder than its Classic cousin.
I refer you to an old ArsTechnica article published back in the Mac OS X Public Beta days:
Mac OS X Update: Quartz & Aqua
And an article published about 10.1:
Mac OS X 10.1: The Window Server
Here's are relevant quotes that I believe sufficiently illustrate my point:
Think about the calculations necessary to do something as simply as move a window in Mac OS X. Every pixel of that window must be re-composited with every pixel of every application in each location for each new position of the window. Imagine a 500x300 pixel window (about 24 rows of 80 column text) moved 100 pixels to the right, with 5 other application windows behind it. That's about 15 million compositing calculations, each with 30 operands (red, green, blue, and alpha values for each contributing pixel from each application), all for moving a small window a few inches.
But wait, there's more. When something changes on the screen (a window moves, appears, or disappears), pixels belonging to other applications are revealed. Those pixels must, of course, be composited before they can be displayed, and those compositing calculations need all the pixel values for each application that has a pixel in the newly revealed area. Adding the compositing calculations associated with the newly revealed screen area in the moving window example above (and accounting for the transparent drop-shadow on the window) brings the grand total to almost 17 million 20-30 operand calculations!
But it's the memory usage that's the real killer. Classic Mac OS applications only need to retain the essential information about each window: its size, features, and contents. Mac OS X applications have to retain the same information, of course, but remember that the window server also has to retain a complete memory image of every pixel in the window! Repeat this for every single window on the screen, and it adds up very quickly.
Classic Mac OS requires only a few kilobytes to store the basic structures that define a simple, empty window. In Mac OS X, the total memory required for even a completely empty window is proportional to its size, regardless of the nature of its contents (if any).
Take a look at this window list from a typical work day on my G4. The total memory used by window buffers alone is an astounding 120MB! And remember, this is before even accounting for things like, say, the memory required by the actual applications and the core OS itself!
torifile has a point on the raw rendering speed. The routines in Win* are indeed in the kernel, much as some of the critical bits of IE's engine are. And yes, that does speed them up while vastly decreasing the stability.
To a point.
At which point Brad and Smircle's explanation kicks in and explains the rest of the speed difference.
Originally posted by Smircle
And Longhorn will be built on .NET/C# which is a vastly more modern developer environment than Apple Cocoa/obj-C.
You *might* have a point on the *environment*, where that's defined as the IDE.
But the APIs? The language? Sorry, but ain't so. I've worked with .NET/C#, as well as Cocoa/Obj-C in various incarnations over the years (Visual Studio/C++/Java, NeXTStep), and have to disagree with you vehemently on this one.
What I've seen of the .NET APIs, cleaning up the cruft of Win32, hasn't really impressed me. *Carbon* was a better cleanup than this, and that's not saying much IMHO. (I hate Carbon programming, just for the record. And the old MacOS Toolbox was hideous.)
C# is an interesting exercise in attempting to co-opt Java into a rather intriguing CLI (where, again, MS has taken a perfectly good and universally acceptable acronym and absconded with it for their own marketing purposes...). I like the concept of the CLI, but much as how I liked the *concept* of the Registry, the implementation leaves a lot to be desired. (I mean really, recrafting goodly chunks of C++'s basic method mechanism to act in a new manner that's incompatible with other C++ code behaviours, and then saying CLI supports C++?? Classic MS.)
Frankly, C# was a really clever academic exercise that should have stayed in the ivory tower. It's neat, it's clever, and it has some good points. But it certainly isn't the end all and be all of programming languages. Only MS could pull off betting the company on something this half-baked.
And I have to report that most of us in academia, when presented with this by the MS folks, were looking at the CLI going "Yeah? So? This is supposed to be *new*?" *shrug* The MS folks couldn't figure out why we weren't signing over our firstborns to them out of gratitude and awe. (Hint: reality disconnect in Redmond.)
I'm hoping that with Xcode, we'll be catching up and surpassing in the IDE department... the extensibility of it has my widdle brain spinning with possibilities. I can't wait to see what 3rd parties come up with.
Originally posted by Kickaha
At which point Brad and Smircle's explanation kicks in and explains the rest of the speed difference.
Not gunna buy it until we see the last of the speed optimizations to the GUI that Apple comes up with. The difference between 10.0 and 10.1 and now 10.2 and soon 10.3 on the same machines is extraordinary. I'm holding fast to my argument that it's not the intensiveness of the GUI that causes these slowdowns. It's other things. And those things are getting worked out...
To me Mac OS X is like Silly Putty...it is smooth and it just feels so dynamic to me and I love how programs interact with each other...even if it is not meant to.
Every update I have seen of Windows I see Microsoft getting further and further away from this kind of experience.
Maybe with Longhorn they will finally do it right but I doubt it. At this point unless Microsoft re-writes their OS entirely from scratch I think it will just be the same OS you see today with a few gimmicks.
What so many people are missing with Mac OS X is that Quartz is not just a fancy "ohhh" and "ahhh" presentation to show who has the coolest OS but it is a truly advanced graphics engine.
I love that I can go in say OmniGraffle and take any image format readable by Preview and rotate it, add transparency, resize, and save it to PDF all on the fly. This to me is what the other guys are missing (Microsoft).
Among having a UNIX core which is another entirely awesome thing that will keep Microsoft far far behind. Not to mention, we have a huge community outside of 1 Infinity Loop that is backing us...