Friday, February 29th, 2008
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.
Robert O’Callahan is much more aggressive and claims platform tilt:
The source to the WK wrappers is not available; the implementations are in a binary blob library that you download with the Webkit sources. It appears the sole purpose of closing the source to this library is to conceal the signatures of the undocumented framework APIs used by Webkit, presumably so that ISVs like us can’t use them.
A key part of Webkit on Mac is kept deliberately closed source by Apple. That’s unfortunate. Instead of hiding the source, a much more friendly policy for Apple would be to make these APIs public as a matter of course. They may argue that there are unfrozen APIs that they don’t want exposed, but there are ways around that, such as by tying symbol names to specific OS versions (CGContextFooBar_10_4?) and promising they’ll just not be there in future versions.
It’s worth reflecting that if Microsoft was doing this, they’d likely be hauled before a judge, in the EU if not the US. In fact I can’t recall Microsoft ever pulling off an undocumented-API-fest of this magnitude.
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.
Posted by Dion Almaer at 7:36 am