Finding the OS X Turbo Button
Firefox developer Vladimir Vukićević:
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.
David Hyatt writes in the comments:
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.
1 Comment RSS · Twitter
Why do Firefox and Safari need to turn of coalesced updates in the first place? Apple provide guidelines (http://developer.apple.com/documentation/Performance/Conceptual/Drawing/Articles/FlushingContent.html) for avoiding performance problems in light of this. Are there architectural reasons these can't be followed?
[This really isn't the place to ask this, I know, but the comment thread is pretty far gone at the original article.]
