http://www.macworld.co.uk/macsoftware/news/index.cfm?newsid=20593
http://blog.vlad1.com/2008/02/28/finding-the-os-x-turbo-button/
It turns out that Apple cheats on OS X to get Safari to render pages through hidden and undocumented API's that other browser makers don't have access to, funny that Apple rigged the contest on their own platform and still can't win. Dave Hyatt, which used to work on Mozilla but went over to the dark side, even fully admits that Apple cheated, using the excuse that to make the API's public would have been a "security risk" (and shipping Leopard without a firewall turned on wasn't?).
Hopefully Mozilla can reverse engineer those API's and let Firefox take advantage of them fully, Firefox 3 is already a hair faster than Safari on the Mac, but this would mean that the only glimpse Safari got of Firefox would be the doppler effect, although most of this Apple garbage has been worked around in Beta 4 and 5.
What's that? Isn't Webkit open source? Yep, most of it anyway, there's at least 100 binary blobs in it without documented source code that lets Apple do things with Safari that no other Webkit app can do! (Who does this sound like? Hint: It starts with Micro and ends with soft!)
I don't like the point where he says Apple probably wasn't being malicious, he's sacrificing his position on the altar of not enraging Mac users, Apple knew what they were doing, and they did it because they don't like the thought of playing second fiddle, especially on their own operating system.
Apple may be boosting Safari speeds with a series of hidden and undocumented API's in OS X that other browsers can't access, a Firefox developer explained last night.
Leading Firefox developer Vladimir Vukicevic explains his discoveries on his blog, which is available here.
He points out that Firefox 3 betas have become more responsive on Mac OS X than they were a few weeks ago, and notes previous complaints in which users had seen poorer performance on OS X than found using Firefox 2.
"Firefox3 was coming in at 50 per cent to 500 per cent+ slower. This was odd, because in theory the graphics layer (which is what scrolling is mostly exercising) in Firefox 3 should be faster, given that it's talking almost directly to Quartz," he writes.
The developer began exploring Apple's WebKit engine for Safari and came across 100 undocumented APIs Safari can call on for better browsing, but Firefox cannot.
Reading the WebKit code is pretty interesting; there are all sorts of potentially useful Cocoa internals bits you can pick up, more easily on the Objective C side (e.g. search for "AppKitSecretsIKnow" in the code), but also in other areas as a pile of these methods used in quite a few places.
"Would any other apps like to take advantage of some of that functionality? I'm pretty sure the answer there is yes, but they can't," he notes.
The developer continued: "We're being throttled by the OS which is forcing us to wait for the next frame interval before allowing us to draw again. This is a pretty serious problem, because at this point I thought that the only way to disable this was on a system-wide basis, which wouldn't be acceptable. Firefox 2 didn't suffer from this, though, so I did some more digging."
The developer doesn't believe Apple is deliberately throttling Firefox speed with these undisclosed APIs, though: "I don't think this is malicious, it's just an unfortunate cutting of corners that is way too easy for a company that's not fully open to do."
Apple's WebKit developer David Hyatt says that it would have been dangerous to make the APIs public: "We aren't really happy with that code in WebKit, but we had to do it to avoid performance regressions in apps that embedded WebKit," he said.
UserAgent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5
