Forgot your password?
typodupeerror
OS X Businesses Operating Systems Apple

Mac OS X Secretly Cripples Non-Apple Software 559

Posted by Soulskill
from the hand-in-the-cookie-jar dept.
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.
This discussion has been archived. No new comments can be posted.

Mac OS X Secretly Cripples Non-Apple Software

Comments Filter:
  • first post! (Score:5, Funny)

    by Anonymous Coward on Thursday February 28, 2008 @10:20PM (#22596134)
    first post!
    i cheated though, i'm using safari.
    • by pedropolis (928836) on Thursday February 28, 2008 @10:28PM (#22596224)
      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?
      • by PJ1216 (1063738) * on Friday February 29, 2008 @07:44AM (#22598608)
        i'm pretty sure "undocumented" means it's *not* in the tech notes... though, i don't write stuff for macs, so maybe you guys use a different definition...
        • by Goaway (82658) on Friday February 29, 2008 @07:53AM (#22598636) Homepage
          The function to turn this on programmatically is undocumented. You're not supposed to do that, you're supposed to set a flag in the app metadata to turn it on. WebKit does it programmatically because it can be embedded in any app.
      • Quote from the article:

        "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 has a reputation: "Slashdot ... in typical style, has completely misunderstood the post."

        It amazes me that, after all these years, Slashdot editors still apparently do not do any research before they post the stories. That has reduced the value of Slashdot as an advertising medium enormously.
        • by ivan256 (17499) on Friday February 29, 2008 @10:00AM (#22599262)
          On the contrary, had the headline not been so sensational, they would have attracted far fewer viewers to the new ad-laden comments section of this particular article. I think the editors have struck a balance between pissing people off enough to get them to click the story, and not pissing them off enough to leave (you're still here, after all).
        • by Lumpy (12016) on Friday February 29, 2008 @10:22AM (#22599468) Homepage
          Why? it works fantastically for Fox-News on cable. they go for the sensational inaccurate reporting for viewiership and accuracy dead last. It's highly effective to the point that they are doing great.

          Slashdot is better because of all the bitching and discussion afterwards on how it's inaccurate.
        • by Overly Critical Guy (663429) on Friday February 29, 2008 @06:58PM (#22606302)
          Whenever someone brings up Slashdot's journalistic integrity, I'm reminded of CmdrTaco's World of Warcraft rant from a few years ago, Blizzard Made Me Change My Name [slashdot.org]. An entire 12-paragraph article because Blizzard made him change his name for using a title in it (Cmdr), which is against the naming rules. That CmdrTaco thought it was news, or that he felt so slighted that he thought he'd "strike back" at Blizzard by posting an article about it on Slashdot because he's CmdrTaco of Slashdot, gosh-darned it, just really showed me how immature and lame this site is.

          The headline "Mac OS X Secretly Cripples Non-Apple Software" will go out on all the feeds. A lot of people won't even read the article. They'll look at it and say "See, typical tyrannical Apple." They may skim the summary and head straight for the comments. And they will be unknowingly misinformed.
    • by FF0000 Phoenix (516214) on Thursday February 28, 2008 @11:37PM (#22596756) Homepage
      It's even more incriminating that all the undocumented APIs are under the "Firefox_Sux" namespace.
  • Article is a Troll (Score:5, Insightful)

    by Anonymous Coward on Thursday February 28, 2008 @10:20PM (#22596142)
    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.
    • by Architect_sasyr (938685) on Thursday February 28, 2008 @10:26PM (#22596194)
      And I thought that the Underhanded C Contest [brainhz.com] would never have come in handy......
    • by Anonymous Coward on Thursday February 28, 2008 @10:33PM (#22596266)
      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: (Score:3, Interesting)

      by Swampash (1131503)
      True. It would have been much more accurate to say that Apple cripples every piece of software equally, and then secretly uncripples its own.
    • by udippel (562132) on Thursday February 28, 2008 @10:54PM (#22596420)
      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.
      • by pavera (320634) on Friday February 29, 2008 @12:26AM (#22597022) Homepage Journal
        The difference here is that the "problem" that firefox was hitting is a completely documented FEATURE and has been around since 10.4.

        Also, There is a 100% documented, public, and simple way to disable the feature. The Firefox dev found this configuration, added 2 lines of XML to firefox, and bam, done, speedy. So I really don't see the comparison to MS at all.

        Also one of the comments on the blog is from a webkit developer at Apple who says "yeah, these APIs basically suck, and they are here for backwards compatibility with Tiger, and they aren't stable, and cause us hundreds of hours of work dealing with regressions, so don't use them, use the perfectly acceptable and documented configuration setting, if there is anything in these APIs that should be made public, it will be once it is stabilized and reliable" He then gives examples of other APIs that have gone through the same process.

        In the end this is 100% open to the public, any software can use this configuration setting to get around this potential performance bottleneck. The reason FF3 was "suddenly" slower than FF2 is they changed from Carbon to Cocoa (2 totally different frameworks) and the new feature is only applied to Cocoa apps. So in short, FF changed hundreds (probably thousands) of lines of code to use a new framework, and found a performance bottleneck, and then found the documentation about it, and changed configuration to avoid the bottleneck... How this is news at all baffles me, that sounds like a normal day in my life.
    • by goombah99 (560566) on Thursday February 28, 2008 @10:54PM (#22596424)
      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: (Score:3, Insightful)

        by Goalie_Ca (584234)
        The undocumented part means that firefox developers can't use it.
      • by RodgerDodger (575834) on Friday February 29, 2008 @12:00AM (#22596870)
        More to the point - there is a public API that can give the same effect (which is used in Firefox 3). Yes, it turns out that WebKit has a similar, but different method - but it's not an advantage that's just for WebKit.

        The FTA even makes it clear - FF3 got the speed advantage they wanted, using the public API. The FTA even has an addition making it clear that the Slashdot article is taking the wrong slant. 'nuff sad.
    • by Ilgaz (86384) * on Friday February 29, 2008 @06:48AM (#22598444) Homepage

      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.
      Firefox developers have no right to speak about OS X too.

      On my Quad G5 with MS Virtual PC 7, I noticed something by accident. I clicked "Yahoo Mail Beta" in IE 6 while emulating X86 and Windows XP same time. You can guess that my hand was on Apple to force it quit since that monster Ajax thing can bring natively (!) running Firefox 2 on OS X down to its knees.

      Guess what? It loaded FASTER on IE 6 running on emulated x86. First thing I did was trashing Firefox.app in my Applications and installing Opera 9 as a old favorite, alternative browser.

      I wish I was a OS X developer knowing OS internals and possible reasons for that scandal performance. First of all, I heard they don't use OS X native Text Rendering to begin with. It can't display Turkish chars right no matter what you do too. I mean, Apple actually purchased licenses of MS Fonts from Microsoft and they are included in Leopard now. "Evil MS fonts" is not excuse anymore, Opera 9.2.6 or 9.5.beta can display them fine. Guess what else displays them fine with total 3% CPU on a site like Digg? KDE Konqueror 3.5.8 installed by Fink project running under unstable OS X Leopard X11! Is it another Apple conspiracy? (!) :)

  • by Valacosa (863657) on Thursday February 28, 2008 @10:21PM (#22596144)

    You don't really have to wonder what Apple is thinking, considering the kind of marketshare Microsoft has gotten for similar practices.
    Fixed.
  • by Anonymous Coward on Thursday February 28, 2008 @10:22PM (#22596156)
    ... but I used a non-Apple browser.

    <sigh>
  • by cobaltnova (1188515) on Thursday February 28, 2008 @10:24PM (#22596180)

    We're capping at 30.77 frames per second here. That's way too round of a number.
    The author must be a mathematician.
  • It IS their right... (Score:4, Interesting)

    by hackel (10452) on Thursday February 28, 2008 @10:24PM (#22596184) Journal
    They are thinking that they are developing a proprietary operating system and they can do WHATEVER THEY WANT. Do not complain about this. It is Apple's right to do this. That's what you get when you make a deal with the devil... Both Microsoft and Apple have the right to cripple other people's software or make their proprietary operating systems run in any way they choose. Just accept it. If you don't like it, I've heard a rumour that there are a few alternatives out there...
  • by linuxpng (314861) on Thursday February 28, 2008 @10:26PM (#22596202)
    how the mozilla team is keeping up with speed in the nightlies w/o access to the hidden APIs?
  • by norkakn (102380) on Thursday February 28, 2008 @10:30PM (#22596244)
    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.
    • by TheVoice900 (467327) <kamil@k a m i l k i s i e l .net> on Thursday February 28, 2008 @10:54PM (#22596426) Homepage
      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.
      • by norkakn (102380) on Thursday February 28, 2008 @11:02PM (#22596478)
        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.
  • by Talez (468021) on Thursday February 28, 2008 @10:34PM (#22596270)
    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?
    • by johne_ganz (750500) on Thursday February 28, 2008 @11:45PM (#22596814)

      You are bang on.

      Display coalescing was introduced way back in 10.4. This was well documented, and as the Firefox developer points out, there's even tools provided to enable and disable this behavior to see if you're being limited by it.

      While I don't know all the details, I would venture to say that far from Apple "Secretly Crippling Non-Apple Software" (which they conveniently provide release notes and debug tools with the stock Xcode tools for this secret behavior), this has exposed a serious performance problem in Firefox.

      To put it another way, display coalescing will effectively penalize apps that are rendering more updates that are physically possible to display. As an extreme example, this roughly equivalent to rendering / writing 60 frames of video to the display in 1/60th of a second, which can only possibly display one of those 60 frames. The rest are just wasting CPU, GPU, and bandwidth resources which could be better spent doing other things. Display coalescing will cause an application to "stall" if it's forcing too many updates, the call to flush the buffer just won't return until the the current frame has fully rendered.

      Mac OS X prior to 10.4 did not enforce this, and so as one of those compatibility trade-offs, display coalescing is turned off by default when certain conditions are detected. I believe anything linked prior to 10.4 will trigger it, and carbon apps. Carbon is essentially for those who are unwilling to (almost literally) join the 21st century.

      Just how secret can it possibly be with publicly available release notes published years ago?

      http://developer.apple.com/technotes/tn2005/tn2133.html [apple.com]
  • Tag "alreadyfixed" (Score:5, Informative)

    by The Iso (1088207) on Thursday February 28, 2008 @10:36PM (#22596288)
    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.
  • David Hyatt response (Score:4, Informative)

    by powermacx (887715) on Thursday February 28, 2008 @11:12PM (#22596570)
    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 [vlad1.com]
  • From the Article (Score:4, Informative)

    by xutopia (469129) on Friday February 29, 2008 @12:18AM (#22596972) Homepage
    "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."
  • by heretic108 (454817) on Friday February 29, 2008 @01:32AM (#22597350)
    In the Linux world, there are 'undocumented APIs' everywhere. Unless of course, one considers a .h file to be documentation.

  • by SoupIsGoodFood_42 (521389) on Friday February 29, 2008 @01:41AM (#22597394)
    It seems quite clear from the comments that this article is a load of crap, yet it still hangs around on the front page, giving skim readers (the majority) false info. Integrity matters, and having user submitted content doesn't change that -- it's still sloppy journalism to let it be published.
  • by stevenp (610846) on Friday February 29, 2008 @05:52AM (#22598280)
    "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.
  • by slashbart (316113) on Friday February 29, 2008 @07:10AM (#22598524) Homepage
    On the Firefox blog Vladimir [vlad1.com] 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.

God is real, unless declared integer.

Working...