As far as I can tell, the proof of this is "I can't see any other reason, so this must be it!" That's hardly solid.

...Apple would use their secret weapon code to improve Java performance, we'd be set!

Perhaps the writer of this post should have read the entire thread before posting to have more of a balanced, less sensational post. David Hyatt (who I believe is heading up development of WebKit/Safari and might now a thing or two about the APIs) Posted what seems to be the official response to this discovery. He points out that there were publicly documented and more importantly, supported methods of achieving the same result discovered by Vladimir, and that the WebKit team is able to implement these APIs as a form of development to bug hunt and ensure that the API's are matured and therefore not a moving target for developers, before they are published.

There is nothing "hidden" or "secret" in an OPEN-SOURCE LIBRARY!

Everything is documented in the code (and yes, it's there in the comments, apparently - according to the slashdot thread on this subject).

In fact, the "hidden code" affecting screen redrawing IS NOT EVEN USED BY SAFARI - IT's TURNED OFF! (It's a hack that's only there to ensure that THIRD-PARTY APPS don't break.)

This story is complete rubbish - in fact, it indicates the OPPOSITE of what the title implies:

"Apple using private WebKit code to fix broken third-party apps"

MacNN, this is plainly bad reporting. The issue has been discussed and closed, but you fail to mention David Hyatt's response.

The final line: "Earlier this month, Computerworld's Seth Weintraub noted that Safari was due for a large speed boost, based on his experiences with the current build of WebKit" is the kicker. Seth's look at the WebKit builds is in no way linked to the story about stubbed placeholder code, and to suggest a link is rather disingenuous.

This issue was already resolved long before MacNN decided to druge it up and use the story for shock value (ad revenue $$). MacNN's reporting is getting worse and worse, to the point that I'm about ready to find my news elsewhere.

Seriously, stop propagating BS. Take the time to understand wtf you're talking about before posting an article so you don't perpetuate what is clearly BS. If you don't understand the technical details of what's going on, find someone who does. Lacking all that, at least take the time to fully read the article, comments and responses. Had you read TFA and the responses on /. or the original post, you would have found a response from the Webkit developers which pretty clearly debunks the poster's whining. If you can't comprehend what the Webkit dev is saying, then please refrain from posting the article because (sorry) you ain't qualified to have an opinion or pass the info on, since you're just going to s**** things up.

Maybe if they had mentioned that the lead developer of Safari replied to Vladimir and explained, in detail, what is going on, then, maybe, this would count as news.

... it must be nice for webkit authors to have firefox authors publicly worry about the competition.

David Hyatt has it explained, and in my opinion as a professional developer and code-quality reviewer is this: the drawing code in computational intensive app should account for the fact that FPS is capped, either by technical constraints or by human eye perception. I hope the next composition engine for FireFox 3 (which will be implemented in next beta, according to Vlad) will hold to this standard, and will effectively use time to next frame instead of just stalling critical computation.