Slashdot Mirror
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.
Ludwig Wittgenstein
And I thought that the Underhanded C Contest would never have come in handy......
Me failed English...
FreeBSD over Linux. If my comments seem odd, this may explain...
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.
Can you tell me who else sells Apple compatible hardware?
Hell, those monopolists even went after sellers of roms to kill emulators.
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.
"You don't need a weatherman to know which way the wind blows." - Bob Dylan
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.
If you look at the article its just stating that the proprietary library has a lot of undocumented functions, and that one of these functions accomplishes a task in a manner that is contradictory to what the Apple docs say to do. The speed gained can be had by sticking a few lines in the .plist, safari happens to use an undocumented API for this, but the end result is the same. Nothing in the article says that the same results cannot be had by third party libs. The rest of the APIs may be useful, but there is nothing indicating that they do something that a third party app cannot do.
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?
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...
Some drink at the fountain of knowledge. Others just gargle.
Developers: We can use your help.
Wrong. The config option was effectively set automatically because Firefox 2 is a Carbon app.
And Safari it's self doesnt use them, and the Firefox team has already made 3.1 much faster than Safari.
It was a non-story that has been picked up by slashdot days late.
"Slashdot, where telling the truth is overrated but lying is insightful."
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
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".
-- Terry
Right, because preventing software from redrawing more often than the monitor can possibly display it is crippling.
This story is really dumb. Basically, the developer is clueless about OS X and isn't aware that the OS throttles drawing. Then instead of doing the right thing and drawing less, he discovers that Safari has an ugly, ugly hack wherein it just does tons of useless drawing but disables the throttling to make it fast. From this he fails to make the right conclusion, that Safari is ass and should be fixed, and instead draws a completely ridiculous conclusion.
"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."
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.
This author takes full ownership and responsibility for the unpopular opinions outlined above.
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.
save the GNUs!
Comment by Hyatt: 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.
# 14 Mick
Technically it's X Window, not X Windows. :-p
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).
It's either "X Window System" or just plain "X".
HAND.
"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."
Slashdot editors - can we drop the sensationalist titles/summaries and stick to reporting the facts?
Dan
"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.
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.
Please at least try to read the linked article. There is a documented way to turn this feature on, which Firefox can easily use, and which the article tells you about.
There is also a hidden API to do this programmatically, which is not of use to anybody except embeddable components which want to override the app settings. Firefox does not need this. WebKit opts to use this, instead of forcing every app developer who uses WebKit to turn on this feature themselves.
Don't blame your own shortcomings on the OS ;p
Actually - this is a good point. These are well known shortcuts to anyone who's been using a Mac for a while, but most newbies (anyone switching in the last 15 years is a newbie in my book - hehe) don't find them, because they're not documented AFAIK - at least not by Apple. Because of this, it's one of the more common sorts of FUD I see bandied around about OS X, that it's mouse-centric.
There are actually very few occasions where you have to reach for the mouse - most things can be done purely with the keyboard, and for those things that don't appear to be possible with the keyboard may well be utilised by adjusting settings in Universal Access and Keyboard System Prefs, including setting up your own global and application level kbd shortcuts.
Oh, and if you think you have to use the mouse to open menus, think again. Try hitting Ctrl-F2. That'll highlight the Apple menu (Esc to exit menu highlighting), then either cursors to navigate or start typing menu name and it'll jump to it, and same within menu items. Hit return to select highlighted item.
There are many undocumented shortcuts. Hitting Option-{special key} (where {special key} is one of the media keys such as volume/brightness/expose etc) will open that particular function's System Pref Pane. And then, of course, you could always opt out of the GUI altogether if you really are that hardcore and live your life in the Terminal... heh! So there you go... hope it proves useful :D
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.
Too bad you haven't read TFA. Let's try one more time:
It's not an undocumented API. It's an alternate way to handle a possible problem, that it self could lead to further problems. Apple has documented all this.
You are an opensource troll.
OK, now?
What the hell are you talking about? The over 10 GB of WebKit Trunk I've got from subversion says otherwise.
They aren't blobs.