Mac OS X Secretly Cripples Non-Apple Software

spikedLemur writes "Vladimir Vukicevic of the Firefox team stumbled upon some questionable practices from Apple while trying to improve the performance of Firefox. Apparently, Apple is using some undocumented APIs that give Safari a significant performance advantage over other browsers. Of course, "undocumented" means that non-Apple developers have to try and reverse-engineer these interfaces to get the same level of performance. You really have to wonder what Apple is thinking, considering the kind of retaliation Microsoft has gotten for similar practices.

Comments

Re:Article is a Troll

[Architect_sasyr]

And I thought that the Underhanded C Contest would never have come in handy......

From the fucking comments

[norkakn]

David Hyatt
Feb 28th, 2008 at 1:24 pm
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.

Re:From the fucking comments

[iluvcapra]

I think you're reading too much malignancy into this, and searing about it and dropping the I-E word doesn't help :).

So WebKit is tightly integrated with the underlying OS service like Internet Explorer is alleged to be with Windows.

It totally is, nothing up our sleeve there, though you don't need webkit to run Finder.app, though under Leopard I bet the QuickView system will break. I think the main complaint about IE was that you can't actually delete Internet Explorer.exe from your Windows system, and it was a finagle to keep Windows from favoring IE for content. Safari.app can be deleted from a Mac with no effort, because Apple actually separated the web rendering system into a library, like the MS people were supposed to.

So, if you use WebKit, you benefit from the private, "better" linkage to the OS service, but if you don't, your performance (or perhaps other qualities) will suffer. Am I getting that right?

You put "better" in quotes because you probably anticipated where the issue is. The OS throttles display updates to the framerate of the display when you run a Cocoa application; this was done to make the drawing to the framebuffer look cleaner and for efficiency reasons (you can read about it here, it's from TFA). If you are building a Cocoa app and want to opt-out of the beam sync, you have to set this option in your Info.plist, which is just a setting built into your deployment (it's really easy, and documented, but they suggest you not do it because it might leave you with a faster-rendering but ugly result). Setting the option in the Info.plist is global for your app, from launch to exit.

WebKit makes use of beam sync on/off, but uses a call into the system to turn it off only at certain times (this is my understanding of Hyatt's explanation). Hyatt, a former Firefox dev himself we might add, himself says this is a hack, and that if you actually expose this functionality to vendors you're totally going to be loading the gun and pointing it at peoples feet.

So what do you do if you're Apple? You can offer people a function that'll turn this efficiency feature on and off, and a few devs might like this, but a ton won't care, and if you do decide to support this, you've gotta make sure it works forever for everybody and perfectly.

Re:From the fucking comments

[goombah99]

because as he plainly said, they wanted the old apps using web kit not to suddenly run slower. As those apps are updated to set the public defaults then they can remove the behaviour from WebKit. that's what he said.

Tag "alreadyfixed"

[The Iso]

The submission is an exaggeration, and this "secret API" nonsense is speculation on the part of the submitter. Firefox's performance has already been brought up to snuff.

Re:Really?

[dal20402]

The Safari performance improvements are coming in Safari 3.1, not yet available to the public. To see them today, you have to be running current WebKit nightlies. The difference between the new WebKit builds and vanilla Safari 3.0.4 is pretty dramatic.

Re:the difference

[cyfer2000]

From David Hyatt's reply, it seems that the webkit team as a whole somehow doesn't like this practice too. David Hyatt was one of the original developers of Firefox and now he is working for Apple.

Re:Dtrace

[byjove]

I can't speak to the rest, but you think it's "almost impossible ... to replace apple programs to default to other ones"? I just changed PDF's to open in Adobe Acrobat instead of Preview by going into Get Info and under "Open With" I selected "Change All". Are you calling this "almost impossible", or am I missing something?

Article points finger in wrong directoin

[goombah99]

The Slashdot summary is accusing Apple of reserving the tasty bits for safari, but the article shows that it's webkit not safari that knows the shorcuts. Anyone is free to use webkit. it's apples optimized interface for applications. If Firefox chooses not to use it well I can understand why but they need to accept that their interface may not be as optimized.

Indeed what apple is doing does not seem that out of whack. They have an interface that is optimized for stability not speed. That's the proper way to do it. and they figure out how one can tweak it for speed. Do you make that the defaults or do you put those in a container like webkit where one can manage the tradeoffs better? duh...

Re:Article is a Troll

[truthsearch]

Possibly confirming your post is this comment on TFA:

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.

David Hyatt response

[powermacx]

If instead of conspiracy theories you are interested in an answer from one of the co-creators of Firefox and who is currently working at Apple's WebKit team, here it is: http://blog.vlad1.com/2008/02/28/finding-the-os-x-turbo-button/#comment-573

Re:David Hyatt response

[pavera]

I didn't read it that way at all. He said "we're using APIs that are secret because they aren't solid yet, and in reality, we hate the secret APIs because they cause regressions and waste hundreds of man hours, as soon as the APIs are stable, we'll make them public".

As for the specific problem encountered in firefox, there is a perfectly acceptable and PUBLIC way of achieving the same thing, so why use the API? Especially since as he mentions in his post, it is the WRONG way to do it.

Re:Article is a Troll

[MouseR]

There is a slight difference in this case though. Unlike compiled C or C++ libraries, Objective-C (/Cocoa) frameworks can be easily turned inside out. The strong method signature nature of the language actually makes it easy to figure out the parameters being passed. If in doubt, just ask at runtime!!

Introspection makes this easy, as in java (and c# I suppose--I'm just guessing for this one).

Also, given Apple did mention it into a post (see above reply) and that although there wasn't documentation per say, the functions were in a published API (in this particular case), one could say "the plans where on display".

Except it IS documented.

[tlambert]

Except it IS documented. He was looking in the header file that documented the API, rather than the one that defined the manifest constant. If he had looked in the one with the manifest constant, he would have seen this comment:

// CoreGraphics deferred updates are disabled if WebKitEnableCoalescedUpdatesPreferenceKey is set
// to NO, or has no value. For compatibility with Mac OS X 10.4.6, deferred updates are OFF by
// default.
#define WebKitEnableDeferredUpdatesPreferenceKey @"WebKitEnableDeferredUpdates"

If all else fails, use google.

-- Terry

Re:Except it IS documented.

[42forty-two42]

There are two seperate APIs here. The one you're looking at is the public one, and the one that mozilla is using - you add a preference entry to your program's plist. WebKit however, made a call to an undocumented function to disable it at runtime; they did this because otherwise programs /embedding/ webkit, where they do not have access to the plist, would suffer performance regressions otherwise. And they plan to remove it once the root cause of the performance issues is fixed (the call disables deferred updates for the entire program that uses webkit, not just webkit itself)

From the Article

[xutopia]

"Edit: Slashdot seems to have picked up on this, and in typical style, has completely misunderstood the post. To be clear, I do not think that Apple is in any way trying to purposely "cripple" non-Apple software. I also do not think that undocumented APIs give Safari any kind of "significant performance advantage" (as Firefox 3 should show!). However, as I said, the undocumented functionality could be useful for Firefox and other apps to implement things in an simpler (and potentially more efficient) manner. 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."

Re:Proprietary software is monopoly software.

[onefriedrice]

All proprietary software developers are monopolists. When you run non-free software you put the monopolists in control. I think you misunderstand what a monopoly is. Under a free market, the success of all products is based on merit, and that has nothing to do with whether it is propriety or Free. You may personally believe in and buy (or use) only software which is Free, but that does not make vendors of propriety software monopolies. That doesn't even make sense at all.

Don't confuse terms. A monopoly occurs when a company or group uses their market position (rather than the product's merit) to cause people to buy their product. Technically, it is quite possible that a Free software vendor could be guilty of monopolistic behavior. Believing that all propriety software vendors are monopolists is a clear logical fallacy as I have demonstrated, so please stop spreading misinformation. The merits of Free software do not increase because you post an irrational rant against propriety software.

Re:From TFA...

[Kyro]

I must say, I've been using Mac OS X since 2002 and have been a part of various mac forums etc.
That is *the* first time I have seen anyone refer to OS X as 'X'.

Very confusing.

Re:Looks pretty secret to me.

[p0tat03]

Except in this case Apple provided a Technical Note that detailed the exact steps you'd need to follow to implement this feature. The only thing that was undocumented was an *alternate* but *functionally identical* way to do it (i.e. doing it from code as opposed to from program config).

No.

[warrax_666]

It's either "X Window System" or just plain "X".

Slashdot seems to have picked up on this

[stevenp]

"Edit: Slashdot seems to have picked up on this, and in typical style, has completely misunderstood the post. To be clear, I do not think that Apple is in any way trying to purposely "cripple" non-Apple software. I also do not think that undocumented APIs give Safari any kind of "significant performance advantage" (as Firefox 3 should show!). However, as I said, the undocumented functionality could be useful for Firefox and other apps to implement things in an simpler (and potentially more efficient) manner. 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."

This pretty clearly sums it up.

Bullshit, ask the original firefox blogger:

[slashbart]

On the Firefox blog Vladimir writes:

Edit: Slashdot seems to have picked up on this, and in typical style, has completely misunderstood the post. To be clear, I do not think that Apple is in any way trying to purposely "cripple" non-Apple software. I also do not think that undocumented APIs give Safari any kind of "significant performance advantage" (as Firefox 3 should show!). However, as I said, the undocumented functionality could be useful for Firefox and other apps to implement things in an simpler (and potentially more efficient) manner. 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.

His finding is that there is a beamsync synchronization, which can possible cause rapidly updating displays to slow down. There are some yet undocumented calls in the Webkit library that allows software to deal with beamsync.

Agreed

[p.rican]

FTFA:

Slashdot seems to have picked up on this, and in typical style, has completely misunderstood the post. To be clear, I do not think that Apple is in any way trying to purposely "cripple" non-Apple software. I also do not think that undocumented APIs give Safari any kind of "significant performance advantage" (as Firefox 3 should show!). However, as I said, the undocumented functionality could be useful for Firefox and other apps to implement things in an simpler (and potentially more efficient) manner. 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.

Re:From TFA...

[cbackas]

They actually are documented. If you go to the "Keyboard Shortcuts" tab in the Keyboard and Mouse preference pane in System Preferences, there's a pretty long list of the default key sequences. You can even globally edit them, and add new ones. (It's even possible to say, globally override something like the "Copy" shotcut in all apps, or add shortcuts for common menu items that don't normally have them)

You can also turn on "Full Keyboard Access" there which enables tabbing between all controls like most non-Mac users expect.