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.

first post!

first post!
i cheated though, i'm using safari.

Um, is this an emulation thing?

From tfa: "The reason why Firefox 2 wasn't affected was that Fx2 was not a Cocoa app"

So writing this from a native perspective introduced new APIs found in tech notes you should have read in the first place before writing and running into performance issues?

Article is a Troll

Oh give me a break, if you use an undocumented API for something that does not mean you "cripple" other pieces of software. It's not like OS-X says "oooo Firefox, quick make it run twice as slow". Grow up.

Re:Article is a Troll

And I thought that the Underhanded C Contest [brainhz.com] would never have come in handy......

Re:Article is a Troll

Yes, the article is a troll at face value. Apple has every right to keep its API secret from 2nd and 3rd parties. It is true however that Microsoft has been widely criticized for not opening up its APIs that give Office, IE, etc. and advantage. What the article is doing is predicting that Apple will be given a pass by the development community, thereby allowing the author to scream "hyprocrisy!" Of course none of this has happened yet, except for your comment. So yeah, the article is a troll.

Re:Article is a Troll

Yes and no. You are correct, using some new shiny and undocumented features for my own good does not primarily and automagically cripple others' products. But as secondary effect, those other products, in comparison, though effectively running at the original specs, look pale in comparison.

Since this is exactly one of the reasons how Microsoft came to dominate the software market, and had all major third parties kowtow to them (and pay) to get the information, the Free Market was distorted. It would not be the best/fastest application that grabbed the market, but the one with knowledge about and rights to the secrets.
I'd have to seriously disappoint you on this one: This is exactly not what the term 'Free Market' means, especially if you are already the monopolist.

You yourself might already have grown up, now try to work on your thinking abilities.

Article points finger in wrong directoin

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

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.

The thinking is really quite simple:

You don't really have to wonder what Apple is thinking, considering the kind of marketshare Microsoft has gotten for similar practices.

Fixed.

*sniffle*

Awwwwww... our little system is all grown up now! Who's a good system? Who's a good system?

Round Number?

We're capping at 30.77 frames per second here. That's way too round of a number.

The author must be a mathematician.

From the fucking comments

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

Thanks for posting this, I was just about to post it myself. This whole story stinks of sensationalism. Do people really think that the webkit and OS X developers sit together in a room and say "Ah.. how can we screw all those 3rd party application makers?". These types of APIs are usually undisclosed because you shouldn't depend on them. Anyone who reads The Old New Thing knows that it's a big problem for Microsoft as well, where developers go digging for some "hidden" APIs only to have their applications break in a future revision of the OS because it wasn't meant to be used.

Re:From the fucking comments

Yeah, that's pretty much exactly why I posted it. IMHO, Apple has been quite good with private APIs. In a major upgrade, they tend to all either become public (often after changing), or die. MS has had a less open history, and I think there are some very valid complaints there, but some are certainly overstated.

Re:From the fucking comments

There is a public way to do the same thing. They just added a total hack to the API to automatically do something by default when WebKit is embedded, instead of requiring a configuration value to be set. They didn't want it to be publicly available since they want the call to die as soon as they figure out a better way to do it. This isn't MS style stuff. There is no hidden feature. You can run the exact same code in a public way, and the it won't break when your user upgrades WebKit.

So, no, you aren't getting it right.

Display Throttling?

Duhhhhh...

Mac OS X 10.4 introduces a new behavior of coalescing updates that enables Quartz to more efficiently update the frame buffer during each display refresh. In addition to increasing system efficiency, Coalescing updates improved visual consistency and eliminates "tearing" during scrolling and animation. To coalesce updates, the Quartz window server composites all window buffers into a single offscreen frame buffer before flushing it to the screen. When your application issues a command to flush, the system doesn't actually flush that content until the next available display refresh. This allows all updates for multiple applications to happen at the same time. Window server operations (window resize or move, for example) are handled in the same manner--coalesced into a system-wide screen update.

I would assume Apple would be thinking this makes a lot of fucking sense.

They give app writers a way to turn it off if need be. What the hell are we crying about again?

Tag "alreadyfixed"

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:the difference

And is that the answer to everything is it? They can do anything that they feel like purely because they are not the dominant player... so all of Microsoft's underhanded playing early on when they weren't the dominant player is all excusable too is it?

It's ridiculous to try and use this insane rationale in regards to any company that's not Microsoft. At what point do you then start going 'well, actually I've decided they have enough market share now, NOW they should be ethical'

Bar and truly humbug

Re:the difference

Monopoly or no, it's undeniable that using secret APIs to give your own software an edge is anti-competitive. Not having a monopoly on the desktop market might mean that it's not illegal, but the legality has no bearing on the ethics.

Re:the difference

How is the use of an API in an open-source project "secret"?

Indeed, where's the advantage?

In Microsoft's case, the goal of keeping "secret" APIs was pretty clear: whoever controls the Windows browser market, controls the browser market, period.

I can just see Steve Jobs rubbing his hands and gloating to his minions..."Yes, and with Firefox handicapped, we will have five percent of the browser market all to ourselves! Ours...all ours! Muahahahaha!"

Re:the difference

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

Garbage!

Microsoft did NOT do "what any sane company would do"! Most sane companies do not deliberately engage in monopolist practices in order to cheat and delude their customers. Microsoft did. There is no argument about that... they have been CONVICTED many times now of doing just that, in both U.S. and European courts!

"Most sane companies" do not do that. MOST companies at least make some effort to engage in Good Business, which involves both parties walking away feeling they got a good deal. That is a far cry from Microsoft's practices, which have largely been "Great! They're in the store! Now, quick, lock the door behind them before they can get away!"

Those are two very, very different approaches. It gained Microsoft a lot of marketshare... at first. But as anybody can see today, those tactics do not keep customers. It pisses them off. And once they find a way out, they tend to stay out.

Re:Really?

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:Really?

If you read the article...

You lost me there.