More 2D Graphics Hardware Acceleration in Mac OS X 10.2
I wonder why no one has discovered this so far...
It just happened to me that while scrolling new Preview's thumbsnails list with a couple of 100 images, web content in IE and especially OmniWeb (where scrolling was painfully slow in 10.1) and content in TextEdit and the open/save dialog columns that I thought: Wait a second, this is much faster than what we have in the current 10.1. How comes?
Firing up QuartzDebug (from the Dev Tools) gave a clear and straight answer. In these cases, moving large chunks of data is not done by the cpu anymore, but offloaded to the graphics card. In 10.1, these tasks are handled entirely by the cpu. (Rule of thumb in QuartzDebug: all areas that flicker are not accelerated, areas that don't are accelerated.)
This is present in both Cocoa and Carbon apps. However, not all applications make full use of this (yet). Interestingly enough, the new Finder uses it only for the scrolling of list views (column view as well). Still, it doesn't seem to be that much of a benefit in windows with huge lists of files. Seems that OS X in generel is having performance issues of handling complex data lists either within or between applications (ever tried to drag 1.000 graphic files to Preview? Takes forever until Preview starts displaying them.) On the other side, scrolling a window's content in icon view mode in the Finder is handled by the cpu.
Basically, scrolling of window content and lists in all Cocoa apps is accelerated. But still, Terminal doesn't use 2D hardware acceleration at all. (Maybe because of the optional window transparency?).
The conclusion: Apple is starting to add the much needed hardware acceleration to the interface we are all looking forward to. In the current WWDC build of 10.2 this is still unfinished, but I guess it is a pretty safe bet that when 10.2 debuts it will be (almost) complete.
Things that need to be done now are many more special case scenarios (content stays the same? ok, fire up hardware acceleration, or in the case of window resizing do not update at all!)
What's currently missing is scrolling of certain custom window content (like a picture in Preview or any other app). Yet again apps like OmniWeb (Cocoa) and IE (Carbon) have their content accelerated.
Anyway, this is excellent news for all of us Mac users. I am on a 400MHz b/w G3 (with a PCI Radeon 7000), and can clearly state that what I see with the WWDC build of 10.2 means that the interface and therefore the whole OS should get a tremendous speed boost once all the things I have mentioned above are fully implemented and complete.
Just wanted to share this with you.
Christopher
It just happened to me that while scrolling new Preview's thumbsnails list with a couple of 100 images, web content in IE and especially OmniWeb (where scrolling was painfully slow in 10.1) and content in TextEdit and the open/save dialog columns that I thought: Wait a second, this is much faster than what we have in the current 10.1. How comes?
Firing up QuartzDebug (from the Dev Tools) gave a clear and straight answer. In these cases, moving large chunks of data is not done by the cpu anymore, but offloaded to the graphics card. In 10.1, these tasks are handled entirely by the cpu. (Rule of thumb in QuartzDebug: all areas that flicker are not accelerated, areas that don't are accelerated.)
This is present in both Cocoa and Carbon apps. However, not all applications make full use of this (yet). Interestingly enough, the new Finder uses it only for the scrolling of list views (column view as well). Still, it doesn't seem to be that much of a benefit in windows with huge lists of files. Seems that OS X in generel is having performance issues of handling complex data lists either within or between applications (ever tried to drag 1.000 graphic files to Preview? Takes forever until Preview starts displaying them.) On the other side, scrolling a window's content in icon view mode in the Finder is handled by the cpu.
Basically, scrolling of window content and lists in all Cocoa apps is accelerated. But still, Terminal doesn't use 2D hardware acceleration at all. (Maybe because of the optional window transparency?).
The conclusion: Apple is starting to add the much needed hardware acceleration to the interface we are all looking forward to. In the current WWDC build of 10.2 this is still unfinished, but I guess it is a pretty safe bet that when 10.2 debuts it will be (almost) complete.
Things that need to be done now are many more special case scenarios (content stays the same? ok, fire up hardware acceleration, or in the case of window resizing do not update at all!)
What's currently missing is scrolling of certain custom window content (like a picture in Preview or any other app). Yet again apps like OmniWeb (Cocoa) and IE (Carbon) have their content accelerated.
Anyway, this is excellent news for all of us Mac users. I am on a 400MHz b/w G3 (with a PCI Radeon 7000), and can clearly state that what I see with the WWDC build of 10.2 means that the interface and therefore the whole OS should get a tremendous speed boost once all the things I have mentioned above are fully implemented and complete.
Just wanted to share this with you.
Christopher
Comments
<strong>Those all sound like pre-computed images that are buffered and scrolled over. In that case it's just the QE compositor doing it's bit. The differences in specific applications may be from how the app is currently handled and whether or not it presents itself to the compositor layer properly to allow off-loading the CPU.</strong><hr></blockquote>
Yes, that's what it seems to me. By using "top" in the Terminal you can also see that both the App and the Window Manager are doing their piece of work here.
The speed difference is dramatic. If Apple pushes this further we'll all be happy as far as the speed of the interface is concerned.