| Monday, March 17, 2003 |
20:52 - No Anti-Aliasing For Oil
http://daringfireball.net/2003/03/antialiasing.html
|
(top)  |
A few days back, John Gruber of Daring Fireball posted an article on one of Safari's quirks: it's too aggressive with Quartz anti-aliasing. Mac OS X's text smoothing is unparalleled, yes; but Safari ignores two aspects of the anti-aliasing model that the rest of the OS properly takes into account: 1) You're not supposed to anti-alias the very smallest fonts; and 2) You're not supposed to anti-alias monospaced fonts.
The thrust of the article is about those monospaced fonts, which Gruber rightly identifies as being useful in the modern world only for "displaying markup and programming language source code." Nothing else. Nobody wants to read text in Courier. Any plain-language text that's rendered in a monospaced font these days is done so only for satirical or legacy purposes, as to simulate a teletype or some such. It's a graphics-based world now, dagnabbit; and unless you're trying to write code or lay out tabular data for rudimentary layout/transport media such as e-mail, monospaced fonts are dumb.
But such uses do still exist; and when OS X apps like Safari try to anti-alias the monospaced fonts that I still use, it's sabotaging a paradigm that had been established way back in Mac history.
Gruber points out a particular example of why it was that the Mac has always been regarded as the prime platform for prepress and text layout. Apple has not just been the company that happened to put all its eggs in the GUI basket and shun the command-line and all its manifestations; it's also been the company that's knuckled down and set itself the task of defining how text and graphics and layout should be done on computers:
9-point Monaco is the last surviving masterpiece of the original Macintosh?s painstakingly hand-tuned set of pixel-perfect bitmap fonts, and deservedly so. Sure, it?s been tweaked in recent years (for example, to distinguish the lowercase L from the digit one, the zero from the capital O, and to enlarge certain punctuation characters, like the period, which originally was just a single pixel), but today?s Monaco 9 would look very familiar to a circa-1986 Mac programmer. Mac OS X introduced a newly refined 10-point counterpart, which feels much larger than the ostensible one-point difference from Monaco 9 would imply. Monaco 10 is also eminently readable, perhaps quite a bit more so than Monaco 9 on today?s high-resolution displays, and yet is very true to Monaco 9?s spirit.
He's got screenshots, too; he's not kidding. Monaco is a nice, nice font for monospaced applications. It's my default font for Terminal and for plain-text e-mail messages in Mail; though these are both Cocoa apps that take full advantage of Quartz rendering, they elect not to anti-alias Monaco and other monospaced fonts.
But just a few days ago, I found myself fiddling around with the prefs in Terminal; I was toggling the "anti-alias text" checkbox and watching the UNIX command-line text shift between smooth and unsmooth, between velvety OS X-y goodness and throwback, knife-edge legacy letting. And you know-- I left that little toggle switch off. The Terminal simply looks better without anti-aliasing on.
Part of it is because Monaco is so carefully tuned to look good without anti-aliasing. But I think it's just as much to do with Gruber's statement that "individual characters carry much more importance in source code than in prose. The ability to discern individual characters is more important than creating on-screen characters that more accurately reflect the style of high-resolution output." I think he's nailed it.
Safari has several kinks to work out; I'd thought that it would turn out to be the best browser at handling text since OmniWeb, since OW used the Quartz layer to its fullest potential and-- quite frankly-- rendered absolutely gorgeous text because of it. Chimera/Camino and IE, by contrast, seemed clumsy and uneven with their text handling; the kerning and leading never quite worked right. I always attributed that to the fact that IE and Camino were browsers that did their own text engines and eschewed the OS-level rendering that OmniWeb took advantage of, for whatever reason. I figured that since Safari was patently the most Cocoa browser to date, then surely it would follow the rules better than any of them. Right?
Well, not quite. How does one explain this?
Check out what happens to the leading on the lines that have italicized text in them. I've highlighted the text so you can see the excess spacing between lines; there should be no white visible. It should be an unbroken block of blue.
I've sent in this bug report already, but I'm starting to think that Safari's adherence to Cocoa standards in text handling is either inadequate, or massively overenthusiastic. I'm not at all sure which.
Incidentally-- and this is only tangentially related-- if anybody is wondering why Safari's performance in handling lots and lots and lots (e.g. hundreds) of form elements on a page is abysmal compared to other browsers such as Camino, it's evidently due to the fact that Safari's reliance on AppKit and Cocoa form widgets is biting it in the ass: AppKit and the Cocoa widgets are performance pigs. They're massively object-oriented, which we've known about forever; this is their blessing and their curse. Cocoa in its elegant architecture has enabled Apple and third-party companies to bring out more new software in less time, over the past two years, than I seem to be able to remember any other company doing in the past. Cocoa is revolutionizing the development process. But the price to be paid for that is the speed penalty that comes with OO design; OO is never as fast as highly tuned procedural code, sometimes very dramatically so. And the upshot is that Safari's performance in meter-pegging performance tests severely lags behind that of apps like Camino that sort of "cheat" and sidle around the OO structure, whether it means they lose the benefit of the OS-level rendering layers or not-- and whether that's a good thing or a bad thing.
I have an 800 MHz iMac here at work, and a 533 MHz PIII running Windows 2000. By any measure, megahertz-myth or no, the iMac should trounce the PC. But if I load a table-heavy page in Safari and IE on the two machines respectively, and start rapidly resizing the window, the Windows/IE contender beats the Mac flat. Why?
Two reasons: 1) IE on Windows is a kernel process; on the Mac it's squarely a userland function. Whether this is "cheating" or not is open to discussion; it certainly can't be denied that it helps boost a very complex set of functions to impossible levels of speed under Windows. But 2) OS X has the OO-ness of Cocoa to deal with, and that does cause a serious slowdown. It doesn't hurt the platform much in raw computational speed, such as in Photoshop filters or SETI@home; but when it comes to UI-intensive interactive work, Cocoa is a big drag.
Now, the good news is that the sunk cost of going to such an OO-intensive framework as Cocoa is just that-- sunk cost. It represents a fairly flat investment of CPU horsepower which will eventually be made irrelevant as the CPUs themselves improve. Just as the OS9 line was tuned to really come into its own with the G3 and especially the G4, OS X is really going to achieve UI "breakout" with the 970 and, in particular, the POWER5-based 9800 which will succeed it fairly quickly. OS X will run on G3s and G4s, but it really wants something with a bit more oomph, and machines with a bit more RAM (512MB is really a practical minimum, I've found) before the user will cease to feel trammeled by it.
What this amounts to is that yes, the Mac is slower than the PC, in many key areas; but that this is not attributable to any one factor, and each of those contributing factors is an investment made for a reason. The CPUs themselves sacrifice raw clock speed for vector processing, short pipelines, and low power. The OS sacrifices computational speed for OO-based developmental ease. The Cocoa widgets and style elements sacrifice feedback speed for looks and consistency. There's an argument to be made in favor of each of these factors; unfortunately, it's a different argument for each one, and the argument against each one has to do with-- yup-- speed.
So, once again, it's all down to "get those dang 970s here already".
And a 30-inch ACD while you're at it.
And bring me some sharks with laser beams on their heads!
|
|
