Mac OS X Secretly Cripples Non-Apple Software 559
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.
the difference (Score:2, Informative)
Re:Article is a Troll (Score:5, Informative)
From the fucking comments (Score:5, Informative)
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.
Yes they are (Score:1, Informative)
Hell, those monopolists even went after sellers of roms to kill emulators.
Tag "alreadyfixed" (Score:5, Informative)
Re:Really? (Score:5, Informative)
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 (Score:5, Informative)
RTFA! (Score:2, Informative)
Re:Dtrace (Score:4, Informative)
Article points finger in wrong directoin (Score:5, Informative)
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 (Score:5, Informative)
Re:Really? (Score:2, Informative)
Wrong. The config option was effectively set automatically because Firefox 2 is a Carbon app.
Comment removed (Score:3, Informative)
David Hyatt response (Score:4, Informative)
Re:Article is a Troll (Score:5, Informative)
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".
Re:From the fucking comments (Score:5, Informative)
I think you're reading too much malignancy into this, and searing about it and dropping the I-E word doesn't help :).
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.
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 [apple.com], 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 (Score:4, Informative)
Except it IS documented. (Score:5, Informative)
-- Terry
Re:David Hyatt response (Score:5, Informative)
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 (Score:2, Informative)
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.
From the Article (Score:4, Informative)
Re:Proprietary software is monopoly software. (Score:5, Informative)
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... (Score:5, Informative)
That is *the* first time I have seen anyone refer to OS X as 'X'.
Very confusing.
Comment By Hyatt (Score:1, Informative)
Techincally .. (Score:2, Informative)
Re:Except it IS documented. (Score:5, Informative)
Re:Looks pretty secret to me. (Score:5, Informative)
No. (Score:5, Informative)
From the article... (Score:2, Informative)
Slashdot editors - can we drop the sensationalist titles/summaries and stick to reporting the facts?
Dan
Re:Article points finger in wrong directoin (Score:3, Informative)
Exactly the same functionality is available to Firefox though a publicly available preference setting.
Slashdot seems to have picked up on this (Score:4, Informative)
This pretty clearly sums it up.
Bullshit, ask the original firefox blogger: (Score:5, Informative)
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.
Re:Techincally .. (Score:3, Informative)
Agreed (Score:5, Informative)
Re:first post! (Score:3, Informative)
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.
Re:From TFA... (Score:2, Informative)
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
Re:From TFA... (Score:4, Informative)
You can also turn on "Full Keyboard Access" there which enables tabbing between all controls like most non-Mac users expect.
Re:Intresting to see the fanboys in action (Score:2, Informative)
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?
Re:Um, is this an emulation thing? (Score:3, Informative)
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.