[adamtki]

Is there a conclusive technical explanation as to why menu displaying and window resizing is so slow? There has been many discussions on it... Even on a default Cocoa application with one empty window, it's slow. I'm testing on a 333 G3 PowerBook. When I run OS 9, the OS feels speedy to me. Is all this due to the unoptimized nature of Quartz and not taking advantage of the graphics hardware acceleration?

[ 07-29-2001: Message edited by: adamtki ]

[AirSluf]

Try click release on the menus, it is MUCH faster than click hold. Instantaneous vs 1/2-3/4 sec on my system.

[adamtki]

It may be a little faster, but either way should be so fast that their speeds are indistinguishable.

[starfleetX]

Originally posted by adamtki:
<STRONG>Is there a conclusive technical explanation as to why menu displaying and window resizing is so slow?</STRONG>

There are MANY reasons it's slow because there are MANY bottlenecks in the system. I could go on forever about the different problems, but I'd rather you read through the forums and do some searches.

<STRONG>Is all this due to the unoptimized nature of Quartz and not taking advantage of the graphics hardware acceleration?</STRONG>

Yes and yes. There's VERY LITTLE hardware acceleration now because there's not much current hardware can do. Arshad (a guy from ATI) was explaining this a while back. He said, IIRC, that further future acceleration would be heavily dependent on the 3D processor because of the layering techniques (not that the UI will actually be in 3D). That's never been done before and will have to be written from scratch. Until now (in OS9 and MS Windows), the 2d accelerators simply copy static bits to and from the screen. However, in OSX there are many more factors. Primarity, the difference is in the vectors...

wait.. okay... I'd better not get into all this now. Like I said, do some searches and you'll get plenty of info.

Anyway, the current builds of 10.1 deliver some fixes in the bottlenecks but the vast majority of drawing is still done by the CPU rather than the 2D accelerator.

[Angus_D]

Window resizing is slow partly because it's live and therefore everything has to be recalculated whenever you move the mouse, unlike in OS 9 (and some Carbon APIs, actually, still) where you got a grey resize outline while you were dragging.

[adamtki]

Well, on a PIII 933 Win2k machine, live window resizing feels very snappy. So I don't see why OS X is so slow. Also, can anyone verify... didn't NeXT have snappy window resizing? If so, it's a real shame that OS X can't do the same since it's a descendant of that OS running on a much faster processor.

The lack of hardware acceleration is part of the problem, but it just feels like mouse click handling in general is slow. When you first try to display a menu, it feels like a whole second (at least) goes by before the menu starts to appear. Clicking on window titles, buttons, tab windows, etc.. all have that delayed feeling. And, of course, this contributes to slow app switching. The finder has that lagging feeling outside of window resizing. Examples are: clicking on a folder, clicking on a toolbar, clicking to start a drag operation, etc...

For those on a G4 or a fast G3, you may not feel the difference, but try running it on a 333 G3 PowerBook.

One day (hopefully in 10.1), all these problems will just go away when Apple releases an update!!