Mac OS X Performance On A G3, Here Are The Answers! February 22nd, 2000 A few weeks ago, I wrote a column about Mac OS X on a G3, and raised questions about how well it would perform on the machines that dominated Apple's product line for a couple of years. As you can guess, the readers reacted and sent me a pile of e-mail, most of which was interesting. What I'll do now is share with you some of the answers I received. They are a bit technical, but you'll want to know what they have to say: Mike McHargue says: All G3-based Macs have pretty good 2D acceleration. The Beige G3 and Rev. A Bondi Blue iMacs are the weakest, using an ATi RAGE II based graphics chipset. The Rev B. Bondi and Rev. C and Rev. D "Yum" iMacs use an ATi RAGE Pro Chipset, which offers better 2D and 3D performance. The Blue and White G3, slot loading iMacs and Rev A. G4s use the RAGE 128 chipset which offers REALLY amazing 2D and quite good 3D acceleration. The AGP graphics G4's also use an improved bus that can really saturate the 128 chip to it's fullest. The Rev. B G4's upped the chip to a RAGE 128 Pro which offers about a 50% speed boost in 3D frame rates. The PowerBook G3 and iBook use a very similar chipset, one is a RAGE Pro and the other a RAGE Mobility. And he adds: The big factor in Aqua performance (which is to say Quartz performance) will be the graphics chip, NOT the processor. Mitchell F. Burt says: all of that elaborate screen drawing in OS X is being done in a completely different graphics space than has previously been seen at an OS's system level - that of vectors. All of that pixel pushing you refer to is a resource hog on bitmap systems because it requires that every pixel of an image be cataloged and mapped, and that transformations require the code to perform operations upon every pixel in the image. Vector graphics on the other hand are constructed from a mathematical description of the image, such as "draw a red line of X thickness for Y pixels in Z direction". While this may seem like a more complicated method, it scales better. Note that when you increase the image size of a bitmap, the file size increases geometrically (assuming bit depth remains the same) as does the number of calculations required to manipulate the image. The same size increase to a vector simply requires that you multiply all of the variables by a common value, and the manipulation overhead does not change, for the most part. This is why Macromedia's Flash is able to deliver relatively complex behaviors with such comparatively small download times to say, Quicktime. This is why Adobe Acrobat files are so much smaller than sending a bunch of scanned pages. Of course you'll note that they look different as well, but this is largely due to a lack of common tools. (The demonstration given of Aqua smoothly resizing a photographic icon as a vector demonstrates that Apple has constructed some of these tools - this should be intriguing to those graphic artists that switch between Photoshop and Illustrator for their bread and butter.) It is funny enough that Mitchell talked about why Adobe Acrobat files (PDF) are smaller than other types of files holding the same documents. As you know, Mac OS X integrates PDF technology and that might be a great reason why visual changes that should have brought a speed hit might just do the opposite after all. Excellent point there, Mitchell. Jason Thacker says: Have you ever seen a G3 run Linux? Same thing. All of the spiffy eye candy is supported by the video card. Any decent card that supports 2d acceleration (i.e. every graphics subsystem in a mac since the late Performas) Should be able to support the nifty graphics. As long as Apple has drivers to enable hardware acceleration, you should be fine. Eric Murphy says: 1) Aqua is running on top of Quartz, not QuickDraw. Everything I've read about Quartz leads me to believe that it will make much more efficient use of processor horsepower than QuickDraw does. 2) Quartz is based on PDF, which is based on PostScript, which is based on vectors, not bitmaps. A move, rescale, or rotation of an icon using vectors is trivial; not so with a bitmap. [Very interesting! -Michael] 2) Aqua and Quartz are running on top of BSD Unix and the Mach kernel, not the crafty mix of PPC and 68k code most versions of Mac OS use (I believe that OS 9 is the first version of Mac OS to be 100% PPC-native code). The efficiencies gained by using all PPC-native code, and the multithreading and multitasking features available under a Unix process model, should more than make up for any slowdowns caused by the animation features of Aqua. Uther Pendragon says: Remember when AppleScript went native? Its speed increased 5x! Apple's main event loop is still 68k based, from what I heard... I could see Apple putting in a lot more stuff in OS X, but I'm sure a G3 will run it fine because it will ALL be PPC native. Maury Markowitz says: I'll tell you why people haven't added these sorts of animation effects in the past. The main reason is that QuickDraw and GDI (MS's version) are terribly outdated. They're VERY slow, difficult to work with, and have tiny little feature sets. I know that sounds harsh, but it's true, and considering QD is almost 20 years old, hardly unexpected... [snipped] QD's (and GDI's) main fault is that when they were built, memory was expensive, but today the average video card has more memory than 4 to 8 whole computers in '91... [snipped] And when you see that super-fancy genie effect, that's nothing more than a few cycles of bit fiddling taking the bitmap of the window from the cache, applying a few cycles of some little transform, then putting it back in the cache. Honestly, there's quite literally nothing to it... [snipped] Here the limits of the draw layer constrain your thinking. No one would even imagine doing Aqua like stuff under QD because there's no cache, you'd have to literally draw ever step of the genie, and indeed, that WOULD be slow! Another major reason is that no one but SJ would have the guts to do something this radical. Simon White says: An element that might be missing from your article "Will Mac OS X Run Well on a G3?" is that Mac OS X has a display architecture (called Quartz) that's fundamentally different from Mac OS 9 and Windows. Traditionally, the OS paints the screen in a "fire and forget" manner, but Mac OS X maintains a database of objects that it manipulates, instead of manipulating the actual pixels on the screen. A window that's in the background really is in the background, waiting patiently to be brought forward. When you do, it happens faster because the OS already knows what that window is and what it looks like. They haven't added bells and whistles to Mac OS 9's graphics system and slowed it down, but instead created a way that's so much more efficient that you might as well add some bells and whistles. The icing on the cake is from an anonymous reader: I have installed developer releases of Mac OS X on multiple G3s (iMac 350MHZ & a G3 PowerBook) and the performance is very acceptable!! Add to this the fact that Apple still manufactures the PowerBook, iBook and iMac with G3 processors, I feel a little better about Mac OS X's performance on G3 computers. It would almost be a crime to have to buy a G4 to run Mac OS X decently, and while I won't go out there and say that each and every G3 is 100% able to run Mac OS X smoothly, it doesn't look so bad when you consider all the technical information given above. I'm wondering how the original iMac and beige G3s will handle all of this, though. Mostly because their graphics cards (ATI Rage II, for example) are not as powerful as the now common Rage 128. Thanks to all of the readers who wrote in, and if you sent me similar information, please don't crucify me for not choosing your message to quote :-) Your comments are welcomed.