Brett (ggtgp@yahoo.com) on 1/17/11 wrote:
---------------------------
>Louis Gerbarg (a@b.c) on 1/17/11 wrote:
>---------------------------
>>Brett (ggtgp@yahoo.com) on 1/17/11 wrote:
>>---------------------------
>>>Its probably due to most Mac Apps using Quickdraw, which was designed around a low performance CPU doing rendering.
>>>Quickdraw only redraws the portions of the screen that has changed.
>>>Same tech used for iOS devices.
>>
>>That is not how Quickdraw ever worked under OS X. All of the region masking stuff
>>was useful on OS 9, but Quickdraw apps under X still draw into regions that are
>>not visible in order to support the fully composited window system. If the background
>>windows were not being updated than things like expose wouldn't work because most
>>of the windows would have stale content, or even sheared content due to partial visibility.
>>
>>That was one of the reasons why Cheetah was so much slower than OS 9, because all
>>of the apps were redrawing constantly, chewing the CPU. Later on things like Quartz
>>2D meant that the Window server could drop some rendering in elided windows, but
>>the apps still need to do basically all the work to figure out what to draw, the
>>only thing different is that is that they can avoid the final blits or OpenGL commands.
>>
>>The optimization you are thinking of is probably drawInRect: being called to avoid
>>drawing a whole view. That is used inside of a single window (and view hierarchy)
>>to avoid drawing parts of views that are completely blocked by other views, but
>>the window still needs to be completely rendered (whereas on OS 9 you could leave
>>half the window unpainted/blitted if you knew it was elided). It is conceptually
>>similar, but in practice entirely different than the old Quickdraw region stuff.
>>
>>In any event, most current Mac apps don't use Quickdraw. It is not part of Cocoa
>>(though it could be used through a special view subclass), it has deprecated for
>>years, it is not available for 64 bit apps, it is not part of iOS. Most apps that
>>do those sorts of drawing tasks these days use CoreGraphics, some use OpenGL.
>
>What goes around comes around.
>NeXt did not have the time money and talent to do everything Quickdraw did, they went with Display Postscript.
>CoreGraphics is a mix of both, with old features re-added over time.
>
>I have found CoreGraphics to be several times slower than OpenGL on the iPhone
>for the games I write. Apple is not stupid so I assume the differences have to do with region update code.

Display Postscript, CoreGraphics, and OpenGL are fundamentally different than Quickdraw. Quickdraw is raster based, CoreGraphics and DPS are both vector based. CoreGraphics is slower than OpenGL because it is doing more than you are doing with OpenGL (or in some cases it is doing the same thing, but has to be more general instead of specializations you can do when you know the specialized constraints of your drawing). NeXT didn't settle for DPS because they couldn't do Quickdraw, they went with DPS because they had a lot beefier hardware and wanted a more advanced drawing and compositing model.

Quickdraw was an amazing piece of engineering when Bill Atkinson wrote it in the early 1980s. I think it would be reasonable to claim it was one of the most valuable pieces of code ever written until that point. But at the end of the day what is was not designed for modern CPUs or GPUs, a number of pieces of its drawing model actually substantially slow down modern hardware, and it doesn't do as much as modern drawing APIs. The current drawing code on OS X and iOS derive almost nothing from it, and that isn't for lack of time or vision, it is because they are trying to do very different things on very different hardware. iOS does make a few choices very differently than MacOS X, both based on experience with compositing on OS X, and the fact that iOS fundamentally assumes it does not need to composite windows from multiple apps together except in very limited circumstances (some UIAlerts, iAds, etc).

I worked at Apple through the early years of OS X, and was on one of the perf teams for much of that time. While I was not personally involved with graphics performance, the guy two offices down from me was and we certainly discussed the issues at length.