2d operations
One of the most serious problems with MacOS X, in the UI level, is the lack of responsiveness in windows operations and especially in scrolling and resizing. It is often said that this is due to the new display layer and/or to "useless eye candy". A more precise explanation, at least for Carbon applications, is given by <a href="http://macsonly.com/arch0112.html#2dosx"; target="_blank">
Prof. Alex Repenning of the University of Colorado.
</a>
The question coming in my mind is the following: does anyone know really what is the source of that problem? Does Apple know also? And if yes, then why the problem remains?
Thanks,
PB
Prof. Alex Repenning of the University of Colorado.
</a>
The question coming in my mind is the following: does anyone know really what is the source of that problem? Does Apple know also? And if yes, then why the problem remains?
Thanks,
PB
Comments
second: the short answer is: double buffering.
Carbon apps window operations are all double buffered. Operations such as scrolling through a file boils down to CopyBits operation moving around pixels in memory. In the case of double buffering there are more bits that needs to be moved and also current programming practice results in some inefficiencies since the new window manager does a more complex task. This explains why all the carbon applications ran significantly slower scrolling than their OS 9 versions.
The fact that Illustrator - a Carbon app - took about the same time to rotate a large image in X versus 9 does not correlate to any kind of optimization. The rotation is an operation only minimally connected by video performance. The amount of work in OS X and 9 are the same. Illustrator does not "take full advantage of the graphics accelerator card" for the rotate operation. Graphics cards have very little acceleration to offer when running 2D types application in QuickDraw. The only thing they can offer is to have a fast implementation of CopyBits and friends but this is the problem since it will not really help all that much with OS X carbon double buffering. The bottom line - currently - is that Carbon apps using QuickDraw functions will be slow wrt video output. There is not much developers can do. Apple on the other hand could, and hopefully will, create better double buffering implementations.
3D application, on the other hand, use OpenGL window managing including OpenGL's double buffering. Even on OS 9 most OpenGL applications use double buffering. Hence there is no big transition between OS 9 and X to begin with. With OpenGL graphics cards can play a much bigger role in optimization.
I hope that explains it. :cool:
<strong>first: he's using 10.1.2 --> no quartz extreme.
</strong><hr></blockquote>
Do you mean that in a quartz extreme enabled mac there is no difference in 2d performance between MacOS X and MacOS 9?
<strong>
Do you mean that in a quartz extreme enabled mac there is no difference in 2d performance between MacOS X and MacOS 9?</strong><hr></blockquote>
no, I wanted to say that in 10.1 there's no such thing as quartz extreme. and because 10.1 is the OS that he uses, it will feel quite sluggish (depends).
for more info on QE : <a href="http://www.apple.com/macosx/jaguar/quartzextreme.html"; target="_blank">http://www.apple.com/macosx/jaguar/quartzextreme.html</a>;
<strong>and btw. did you read second: ?</strong><hr></blockquote>
Of course, but this refers only to Carbon applications (and I am not sure if that's all the story). What about Cocoa?
<strong>
for more info on QE : <a href="http://www.apple.com/macosx/jaguar/quartzextreme.html"; target="_blank">http://www.apple.com/macosx/jaguar/quartzextreme.html</a></strong><hr></blockquote>;
OK, I know, but it is Apple's test on some unspecified machine. What "real people" with precise machine specifications say about that?
<strong>Carbon apps window operations are all double buffered.</strong><hr></blockquote>No, ALL windows are double-buffered (unless very specifically programatically omitted, which is difficult unless the app goes "full screen"). This applies to all windows, Carbon AND Cocoa.
For an explanation of how the windowing system works in Mac OS X, why it is VASTLY different than OS9 and MS Windows, and why it is typically slower, I highly recommend John Siracusa's articles on 10.0 and 10.1, specifically these pages:
<a href="http://www.arstechnica.com/reviews/1q00/macos-x-gui/macos-x-gui-2.html"; target="_blank">http://www.arstechnica.com/reviews/1q00/macos-x-gui/macos-x-gui-2.html</a>;
<a href="http://www.arstechnica.com/reviews/1q00/macos-x-gui/macos-x-gui-3.html"; target="_blank">http://www.arstechnica.com/reviews/1q00/macos-x-gui/macos-x-gui-3.html</a>;
<a href="http://arstechnica.com/reviews/01q4/macosx-10.1/macosx-10.1-6.html"; target="_blank">http://arstechnica.com/reviews/01q4/macosx-10.1/macosx-10.1-6.html</a>;
(scroll down about half-way to "The Window Server")
Of course, with the release of 10.2, these articles are slightly dated. 10.2 does enable window buffer compression as John alludes to in the second link. 10.2 also brings GPU-accelerated compositing (Quartz Extreme) that significantly reduces the CPU overhead of Quartz.
[quote]Originally posted by PB:
<strong>OK, I know, but it is Apple's test on some unspecified machine. What "real people" with precise machine specifications say about that?</strong><hr></blockquote>Until you see Quartz Extreme in person, you really can't know how *greatly* it improves performance. For some more numbers, here's another one of John's articles, this one about 10.2:
<a href="http://www.arstechnica.com/reviews/02q3/macosx-10.2/macosx-10.2-8.html"; target="_blank">http://www.arstechnica.com/reviews/02q3/macosx-10.2/macosx-10.2-8.html</a>;
<a href="http://www.arstechnica.com/reviews/02q3/macosx-10.2/macosx-10.2-9.html"; target="_blank">http://www.arstechnica.com/reviews/02q3/macosx-10.2/macosx-10.2-9.html</a>;
Does this help any?
[ 09-12-2002: Message edited by: Brad ]</p>
[QBCarbon apps window operations are all double buffered. Operations such as scrolling through a file boils down to CopyBits operation moving around pixels in memory. In the case of double buffering there are more bits that needs to be moved and also current programming practice results in some inefficiencies since the new window manager does a more complex task. This explains why all the carbon applications ran significantly slower scrolling than their OS 9 versions.[/QB]<hr></blockquote>
The way I understand it, Quartz double buffers everything equally. Quickdraw doesn't, so to get double buffering under OS 9, the developer has to do their own double buffering. The problem is that some developers forgot to disable their own double buffering when running under OS X, so those apps are triple buffered on OS X. It's this triple buffering that slows down some Carbon apps.
Edit: removed duplicate text (pasted it twice)
[ 09-12-2002: Message edited by: Whisper ]</p>
<strong>
The way I understand it, Quartz double buffers everything equally. Quickdraw doesn't, so to get double buffering under OS 9, the developer has to do their own double buffering. The problem is that some developers forgot to disable their own double buffering when running under OS X, so those apps are triple buffered on OS X. It's this triple buffering that slows down some Carbon apps.
Edit: removed duplicate text (pasted it twice)
[ 09-12-2002: Message edited by: Whisper ]</strong><hr></blockquote>
That sounds about right.
I was writing some java stuff and my program never flickered for me because OS X is always double buffered, but I had to add double buffering to the program so it wouldn't flicker for people who aren't fortunate enough to be using Mac OS X. Sadly, that means it runs somewhat slower for me because it's effectively triple buffered.
<strong>No, ALL windows are double-buffered (unless very specifically programatically omitted, which is difficult unless the app goes "full screen"). This applies to all windows, Carbon AND Cocoa.
</strong><hr></blockquote>
sir, I didn't said that ONLY carbon apps are double buffered. I just didn't specify it clear enough.
[ 09-12-2002: Message edited by: Defiant ]</p>
<strong>Until you see Quartz Extreme in person, you really can't know how *greatly* it improves performance. For some more numbers, here's another one of John's articles, this one about 10.2:
<a href="http://www.arstechnica.com/reviews/02q3/macosx-10.2/macosx-10.2-8.html"; target="_blank">http://www.arstechnica.com/reviews/02q3/macosx-10.2/macosx-10.2-8.html</a>;
<a href="http://www.arstechnica.com/reviews/02q3/macosx-10.2/macosx-10.2-9.html"; target="_blank">http://www.arstechnica.com/reviews/02q3/macosx-10.2/macosx-10.2-9.html</a>;
Does this help any?
[ 09-12-2002: Message edited by: Brad ]</strong><hr></blockquote>
Thanks for the very informative links. However, as John notes in these articles, window resizing (and scrolling also, although improved) is still very slow, even under Quartz Extreme. John also says that the reason for this resizing problem is not apparent. This seems to be in contradiction with Apple's tests on QE, which give nearly 4 times faster performance for resizing under QE. I am a bit confused...
<strong>Wouldn't Window Buffer Compression add more overhead to the rendering process?</strong><hr></blockquote>Not at all. The time it takes to compress and send data is LESS than it would be just to send the data uncompressed. Andrew Welch (aka. moki, of Ambrosia SW fame) went into a thorough explanation of the whole process at MacNN's forums. He's the one that found the code that allowed you to enable buffer compression in 10.1.
moki == god.