Vladimir Vukićević has posted on the performance improvements of Firefox 3 on the Mac, and how one hack, albeit “dangerous” has helped ton. Vladamir says:
While figuring all this out, I noticed that Safari/WebKit didn’t seem to be affected by this framerate cap — the fps meter when Safari was running the same benchmark happily went up beyond 60fps. After I found the plist entry, I checked Safari’s plist and was surprised to discover that they didn’t have this disabling in there. Doing some more searching, I found this code in WebKit. Apparently, there is a way to do this programatically, along with some other interesting things like enabling window update display throttling (though it’s unclear what that means!) — but only if you’re Apple.
All these WK* methods are undocumented, and they appear in binary blobs shipped along with the WebKit source (see the WebKitLibraries directory). There are now over 100 private “OS-secrets-only-WebKit-knows” in the library, many of which are referred to in a mostly comment-free header file. 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 WK* 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. It’s not even clear under what license libWebKitSystemInterface is provided, so that other apps can know if they can link to it.
David Hyatt, the guru lead of Webkit/Safari commented:
The programmatic disabling of coalesced updates should not be public API. It’s actually a very dangerous thing to do. 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. Technically it’s wrong though, since we turn off the coalesced updates for any app that uses WebKit! This includes drawing they do that doesn’t even use WebKit.
As for the window display throttling, that was a pref designed for Safari (that we don’t even use any more). It’s not private or magic. It’s nothing more than a pref that we can examine from Safari-land, so linking to that is just silly. 
Many of the private methods that WebKit uses are private for a reason. Either they expose internal structures that can’t be depended on, or they are part of something inside a framework that may not be fully formed. WebKit subclasses several private NSView methods for example, and it cost us many many man hours to deal with the regressions caused by the internal changes that were made to NSViews in Leopard.
As you yourself blogged, there was a totally acceptable public way of doing what you needed to do.
For any private methods we use that we think should be public, we (the WebKit team) file bugs on the appropriate system components. Many of these methods have become public over time (CG stuff in Leopard for example). Be careful when you dig into WebKit code, since we may continue to use the WK method even though it’s not public API just because we need to work on Tiger.
WebKit flies on my Mac, and Firefox 3 has almost caught up. The end result is that I am pretty happy with how browsers are improving their performance, and I am sure there is a lot more to see.
