John Gruber of Daring Fireball (thanks for the link!) knows a lot about font-rendering, however in a recent post discussing screen-rotation and sub-pixel text rendering he let this slip:

“I tested it on my Cinema Display with the screen rotated 90°, and, to my eyes, sub-pixel anti-aliasing still looked good.”

That is just preposterous. Aside from his observation being completely wrong, he also revealed a bug in OS X: The current system doesn’t recognize rotated pixel orientations, sub-pixel rendering on rotated screens should probably be disabled automatically. (rdar://problem/5627732)

Here are two screenshots of my browser’s address bar as displayed on my Cinema Display, which clearly shows the difference. The top image is Leopard’s default sub-pixel rendering. The second image is the same bar photographed with my display rotated 90°, the photo was then rotated back in Photoshop for better comparison.

The text was apparently calculated against the presumed horizontal LCD primary orientation. But because the pixels were rotated, several of the letterform stems (verticals) are drawing as full-pixel-width colored lines. The first “h” is especially glaring, its stem and stroke are drawn as a pair of dark red and light blue lines.

Sub-pixel rendering takes advantage of a known horizontal alignment of the three color primaries that make up each physical pixel. The algorithm seems to render text at 3x the horizontal resolution, ignoring the color information and treating each third-pixel as a valid light source to use for drawing letterforms. That 3x width is then striped with red, green and blue to match screen’s component primary ordering. (That was an educated guess)

As Steve Weller stated in the post John linked, the human eye has “pathetic color-resolution”. This fact is exploited all over the place in video, with many formats sampling color only once for every four luminance pixels.

Several things are at play here:

1. Human vision is the bifocal product of horizontally arranged eyes.
2. Most written human language uses letterforms which are vertically oriented and horizontally distinguished. Especially Latin-derived languages.
3. Most human languages read horizontally.
4. Human vision tends to be less color sensitive for motion, or when scanning information (like reading)

It all just kind of worked out perfectly. Digital color reproduction combined our horizontal predisposition with our soft and slow perception of color, and then arranged color primaries horizontally. Text also reads horizontally, and since the viewer is rapidly moving their eyes, we perceive shape and contrast before color. Additionally, Latinate languages evolved letterforms which utilize horizontal variations against a largely regular vertical syncopation. Presto: sub-pixel rendering just seems fantastically obvious.

Regarding John’s closing supposition,

“I’m not sure the iPhones rotating display is reason enough to rule out sub-pixel rendering.”

Based on everything leading up to sub-pixel rendering in the first place, most of the benefits would be lost if the underlying pixel grid was vertically oriented. The sensitivity of computer text falls across the horizontal axis. Adding resolution to the vertical axis isn’t worth the effort.

Sub-pixel rendering is ultimately a transitional technology anyway, a half-step that improves the now while waiting for a better and inevitable future to arrive. Once we start seeing iPhone level pixel-densities all over the place, sub-pixel rendering will began its transition to technology footnote.

Digital displays will someday reach a point where every physical pixel is capable of producing every color of visible light. (And someone will doubtlessly push into near infrared and ultra-violet, claiming increased realism and fidelity). Future displays will also be operating at a density where anti-aliasing may not be necessary at all.

I still think Apple’s decision to use standard anti-aliasing for the Leopard menu bar was a mistake. Unless they’ve got some spiffy high-pixel-density cinema displays ready for MacWorld and enable system-wide resolution independence in 10.5.x, switching to standard anti-aliased text rendering in the menu bar was a change that should have been postponed. The necessary hardware pool just isn’t here yet and the result is an interface that looks markedly worse than it did under previous releases.

Lately I’ve noticed the Finder on my MacBook Pro has been running both CPU cores at 40-80% for no apparent reason. From what I’ve been able to tell, there is a bug related to having the same window open in two different spaces with Calculate Folder Sizes enabled. I filed a bug on this (5609348) but Apple is already aware of this issue.

Workaround: Closing all the Finder windows (⌘-w) seems to bring the Finder’s CPU usage back to zero.

The following steps will recreate the problem every time for me:

1. Log in to the guest account
2. ⌘-up arrow twice (navigate up from guest user’s home folder)
3. ⌘-2 (list view)

4. Open System Prefs
5. Enable Spaces with default options.

6. Open Activity Monitor (via Spotlight), search for “Finder” to clean up display
7. Arrange windows so the CPU value is visible behind the window

8. Switch to another space
9. Create a new window: ⌘-n, ⌘-up arrow twice, ⌘-2

10. Switch back to first space
11. Click Finder window to be sure it’s selected (probably unnecessary)
12. ⌘-J (Show View Options)
13. Check “Calculate all sizes”

CPU usage should now increase. On my MBP I see about 40% across both cores.

14. Uncheck “Calculate all sizes”

CPU usage increases to as much as 80%

A few notes:

The window should have a lot of files underneath it. If the Calculate all sizes command finishes too quickly it won’t show the problem. I opened windows to the top level of the hard drive because there weren’t enough files in the default guest account home folder.

This behavior did not happen with both windows in the same space.

Amazing how times change:

Originals found here, via Shawn King on Twitter

Update: Amazingly, iPhone 1.1.2 update re-enabled the m4r-rename hack. This all works again!

I just tested it quickly by renaming a previous home-made ringtone file to m4r and double-clicking. It imported, synced to and played on my iPhone without any other steps.

Currently there are no known ringtone hacks for iPhone 1.1.1.

Apple, you’re pissing off your fans. Don’t do this. [we’ll just be over here pretending you listened!]

This totally seems like it shouldn’t work.

If you’re seeing “cannot be played on this iPhone errors” like this:

Open your iTunes Library folder and find the Ringtones folder: iTunes Music/Ringtones.

Select your ringtone and change the file extension back to m4a. Yes, m4a.

Sync again and your custom ringtone should be working on your iPhone. Nice.

Update: Confirmed for Windows XP & Vista

Thanks to commenter Robbie, building on steps from Jason Choi, here’s how to get custom ringtones working in Windows:

1. Put m4r files into a ringtones folder on my desktop
2. Opened iTunes
3. Edit > Preferences > Advanced
4. Check “Keep iTunes Music folder organized”
5. Check “Copy files to iTunes Music folder when adding to library”
6. Create playlist called “Ringtones” in iTunes
7. Drag the Ringtones folder from my desktop to the playlist I created in iTunes
8. Made sure they appeared when in the list on the Ringtones tab in iTunes
9. Opened the “Ringtones” folder that iTunes created in MusiciTunesiTunes MusicRingtones
10. Renamed all the m4r files to m4a
11. Try to sync but it fails because it cannot find the m4r files (this is good)
12. Look at playlist created in iTunes with a bunch of Xs next to each ringtone
13. Double click each ringtone (hit browse for the file, and selected each m4a file from the folder in my MusiciTunesiTunes MusicRingtones)
14. Hit sync again
15. Verify they are in your Settings>Sounds>Ringtones

Me, yesterday:

The price drop on iPhone was shocking. I was all set to buy a new Nano, but the idea that my iPhone now costs one-8GB-nano less has me waiting. This seems like a big enough PR blunder, or setup, that Apple will followup with some easy goodwill. I’m still going to get a new nano, but I’m going to wait at least until the weekend.

Today Apple does it again: To all iPhone customers

…[W]e need to do a better job taking care of our early iPhone customers as we aggressively go after new ones with a lower price. Our early customers trusted us, and we must live up to that trust with our actions in moments like these.

Therefore, we have decided to offer every iPhone customer who purchased an iPhone from either Apple or AT&T, and who is not receiving a rebate or any other consideration, a $100 store credit towards the purchase of any product at an Apple Retail Store or the Apple Online Store. Details are still being worked out and will be posted on Apple’s website next week. Stay tuned.

We want to do the right thing for our valued iPhone customers. We apologize for disappointing some of you, and we are doing our best to live up to your high expectations of Apple.

I think they fully expected this reaction having done something similar to quell outrage after dropping the price on Aperture last year. It’s a win-win for Apple, if there was no outrage, then eh, they just sell more phones. If there is outrage, as there was, Apple wins, probably more.

The intial news cycle only lasts so long, Apple got some press for the new iPods yesterday, then got more as the media picked up on all the iPhone owners who felt robbed.

All publicity is good publicity.

Apple waited just long enough for things to die down a little, then grabbed everyone’s attention again with a remarkable conciliatory, gesture of goodwill. Happy customers, more coverage. The initial news cycle stretched two or three times what it was and ends on an undisputed high note.

It’s called public relations for a reason. How much does it cost to grab people’s attention? How much to stay at the top of the news cycle?

Apple is playing the game masterfully.

And my new iPod nano is suddenly half off.

Pre-event predictions:

• touch iPod, basically the iPhone without the phone
• Some sort of mobile iTunes Store
• new version of iTunes
• iPhone software update with some noticeable new features
• still no iPhone SDK
• New iPod Nano (predicted here)

Other than that, I have no idea. I’ve got a bunch of browser windows open and will be posting on Twitter. Reactions posted here a little later.

Aftermath

Overall, a pretty impressive run of new stuff. I’ve also never been this accurate in predictions, basically 100%, although there wasn’t much swinging for the fences in that list.

iPod Nano

I’m getting one. Mostly for Nike+, but I do really like the new form factor. It’s astonishing how small these things are getting. The colors seem very mid-80s, but I expect the metal will have have more depth in person. One more video-playing device won’t hurt to have on the next plane flight either. (can we get Yo Gabba Gabba on iTunes pls?)

iPod Touch

The iPod Touch looks great, but I’m mostly surprised at how much it doesn’t do.

• No Email
• No Maps
• No Stocks
• No Weather
• No Notes (not that I’ve ever actually used iPhone Notes)

If email was there I’d be hard pressed to justify breaking an existing phone contract for iPhone. But the missing features are most likely conscious choices to differentiate iPhone and to maintain the focus of iPod. There’s room for the inevitable To Do List application which will come alongside Leopard’s To Do list framework.

iPod Shuffle

The iPod Shuffle is close to a perfect product. We got one as a gift early this year along with one of the best wooden watches and we both love using it at the gym. New colors, it really doesn’t need much else, except maybe an internal clock and a bit more space.

iPhone Price Drop

The price drop on iPhone was shocking. I was all set to buy a new Nano, but the idea that my iPhone now costs one-8GB-nano less has me waiting. This seems like a big enough PR blunder, or setup, that Apple will followup with some easy goodwill. I’m still going to get a new nano, but I’m going to wait at least until the weekend.

iTunes Everywhere

The iTunes & Starbucks integration is jus asonishingly huge. This is the beginning of a complete re-imagining of how recorded music works. The idea of a “record store” just evaporated throughout the air we breathe. In a few years this system will be used all over. Any place that plays music will be able to enter into a music distribution profit sharing arrangement with Apple. Doubtlessly they’ll also be able to use custom playlists to promote local or smaller artists. This is the beginning of iTunes Everywhere. Anytime you hear a song, you will be able to take out your iPod and buy a copy. I fully expect to see this in the Apple Stores in a few months as well.

This was the promise, it’s finally happening.

Valerio Proietti, author of the MooTools JavaScript framework wrote a benchmarking tool called SlickSpeed. This tool runs a number of JavaScript libraries against a suite of CSS selector tests. The source is available from Google Code, I downloaded a copy so I could run tests against the most recent versions of Prototype, MooTools and JQuery against one another.

Results are in milliseconds (ms), smaller numbers are better. Asterisks indicate errors returned during the test.

All tests were served and run from a MacBook Pro 2.16 GHz Core Duo, iPhone tests were run on a 1st Generation 8 GB model. Firebug was disabled for the Firefox tests.

A few things which are immediately apparent:

MooTools is a solid performer. Not the fastest and not the slowest, but Valerio Proietti’s code is consistently impressive.

JQuery has gotten significantly faster in the most recent version, John Resig is also writing really good code.

At least as applies to Valerio’s set of selector tests, JQuery is the fastest library on iPhone, nearly twice as fast as MooTools and almost three times faster than Prototype. Joe Hewitt’s iUI project uses Prototype, how much would iPhone performance benefit from switching to JQuery?

The Webkit team is writing some seriously crazy speed optimizations. If they could just get Safari to stop leaking memory we’d be all set (don’t go looking all smug Firefox, you’re standing in a puddle). As it stands now, when Leopard ships Safari will have the fastest JavaScript engine available. The difference between jQuery and Prototype on Webkit and iPhone is surprising, iPhone runs JQuery nearly three times faster than Prototype using the same browser core.

Firefox runs faster in virtualized Windows than it does native on the Mac. Camino (Mac native version of Mozilla/Firefox/Gecko) was slightly faster, but still not as fast as Firefox Windows.

I’ve got one project wrapping up soon which used MooTools and I’ve been very happy with it. Lately I’ve been reading a lot of buzz about JQuery and might be working that into another project. These tests were mostly just done to satisfy my own of curiosity.