Thats a very interesting discussion! It is true that UI drawing in Windows is generally quicker than UI drawing in OS X. I find it curious that you mention that the performance in OS X has decreased since 10.7, as it should actually have
increased: this is the time where Apple started actually porting its apps to Core Animation which relies on heavy caching of images to speed up the drawing and enable new advanced effects.
Overall, I have been programming for Windows and Linux for at least a decade, and from my experience, I can say that the programming and drawing model in OS X is just much more advanced and involved. Especially before the advent of .NET, UI in Windows was just extremely primitive. Especially things like text layout. In comparison, OS X drawing APIs take much more care of details, like text alignment and UI element styling, which is inherently also slower. Same thing goes for animations. Believe it or not, but complex animations are
everywhere in OS X. They are just so subtle that it is almost not noticeable but they result in a higher perceived quality of the interaction. Of course, it is an additional performance hit. One good example of all this is Mission Control: it shows all changes in all windows
in real-time. This means that the OS has to potential redraw all windows that are changed. And if you have some applications that are redrawing slowly or too frequently, Mission Control would lag. Of course, it is possible to optimise this drop the live update of windows that fail to finish drawing within a predetermined time interval.
Of course, the above does not mean that it is impossible to write OS X software that can draw quickly. It is in fact very possible, but one needs to take extra care of that. The truth is, on Windows it does not really matter. As you just do dumb, primitive drawing most of the time, you can do a lot of mistakes in your code before the performance hit becomes visible. But as drawing is more expensive on OS X, you should be aware of what you are doing and optimise your code. Much of OS X lag comes from sub optimally written applications. I once had to develop a cross-platform application that was using a lot of text labels. It was
extremely slow on OS X. After some digging I found out that the method I was using to draw those labels (NSString's drawAtPoint:withAttributes
is meant as a high-level convenience utility AND not recommended for heavy usage. I have rewritten the code by directly using the OS X text layout engine and immediately received a dramatic speedup.
So bottomline: OS X drawing is often more expensive and the developer needs to take care that it used efficiently. This is especially true for retina displays. Unfortunately, even Apple's own apps suffer from heavy efficiency issues...