I went to THE MAC STORE today and got my hands on a 1.6 and 1.8 G5. Let me just say that I did no benchmarks, nor do I have any intentions of doing any benchmarks so please do not ask. I think that they are rather silly for the most part. I was interested in performance, however. I am thinking about getting a more powerful machine to resurrect my DAW. I have a friend there and we spend quite a bit of time talking Mac. Frankly, I was a little disappointed with what I saw. My unofficial test for Mac performance is scrolling a long document. When you move the slider, the document should move exactly with the pointer no matter how fast you move it. This is true in OS 9 and Windows. It demonstrates how the OS feels, QE and all that. Well, it did not do all that well. There are no miracles here folks. I know this is just one element of the GUI, but this is what OS X is based on. Yes, yes, I already know about the expected improvements in Panther. I grow a little tired of waiting for software solutions for performance deficiencies.
It could be said that my tests of the 1.8 were a bit unfair because it was encoding MP3s at the time. The CPU meter showed 100% usage. On this machine, I tried iSight for the first time. I was not impressed. The image was quite choppy. The salesman said that it was because the processor was under load. I hooked the iSight up to my iBook and it was still choppy and the salesman said that it was because it was a G3. He promised that the iSight really worked better than was he was able to demonstrate at the time. I will just have to take him at his word. It is quite possible that the dual 2 will be able to handle a processor intensive task and something else without taking a big performance hit. I hope so. But for those who believe that the G5 is the end all to all of Apple's performance issues, IT IS NOT! There is no magic here people so don't drink too deeply of the Kool-Aid.
The architecture may in fact lead to revolutionary performance gains. But the current iteration of the SP G5 is evolutionary at best. I would love to see the real world performance of a dual G4 in comparison. I do not have hands on experience with G4 towers. I never had an interest in them until now. My experience with the 1.6 and 1.8 really made me think that duals are the only way to go for the Mac. I will also acknowledge that either machine would probably be sufficient for audio work I would hope that running 16 stereo tracks with two or three filters per track would not bring the system to its knees. But after the demo I had in the store today, I'm not so sure.
There were some things I liked, the design is nice, though it is really big in person. You can feel a pocket of cool air in the front of the machine and warm air blowing out of the back. I heard the fans going at full blast and it was not that bad. By the way, the air coming from the back was not very hot at all. Good job, Apple. Menus were snappier than I was used to. But remember, I have an iBook.
My conclusion, this may be a very good, if not expensive upgrade for people with a low end Macs. Certain pro tasks may see a nice speed bump in specifically optimized programs. I do not know what kind of improvement it represents for general computing. I still use my PC for heavy lifting. (I am not a PS user.) This is not a slash and burn review. This is not a review. It is the first impression of a not overly technical guy that loves computers on any platform and who happens to be in the market for his next tower. Please don't bog this thread down with benchmarks. Try to keep the discussion in layman's terms. If there is no discussion, that's OK too. I hope this post is helpful to someone.
Cheers.
Are you sure [about the scrolling]? Even on my "weak" 900Mhz iBook, scrolling is pretty good. The scrollbar seems to lag more than the scrolling.
so what you are saying is that you want iTunes to NOT use 100% of the CPU (and therefore cripple it's own performance) ? Well, if that's what you want, then you can use Unix's 'nice' command, to lower the process priority.
I don't think I've ever seen text not keep up with the scroll bars, except in something like Hydra with syntax colouring turned on and a very long document.
You really didn't give the G5 or the iSight a fair chance. Go back, turn off iTunes, and I think you'll be impressed.
...and yes, I know you don't want to hear this, but Panther really does make a huge difference.
That reminds of an interesting thing from ArsTechnica... apparently iTunes (at least when playing music) has a unique way of being "indestructible". Instead of using 'nice', iTunes seems to have a way of taking over the machines processor, getting even more power then -20 in 'nice'.
10.2.7, aka Smeagol, on the G5 can be considered a "hack job", FYI. It's just a quick fix to get the OS to *run* on the new processor. It is very un-optimized for the G5 and uses the old compiler that's designed for the G3s and G4s. It was stated months ago that Smeagol would be slow and would make the G5 look slower than it really is.
Panther is the OS that is *meant* for this machine not just because it offers performance gains across the board but also because it uses the updated gcc. Panther will make the G5 fly compared to Smeagol.
Don't get any ideas yet guys.... The G5 will be VERY VERY good, but not yet! we need panther. also the 256MB of ram probly isn't that great for the curent OS X
10.2.7 witch is NOT made for the G5 it doesn't take advantage of ANY of the G5 features.
There ONLY goal for 10.2.7 is to let it run with onpar preformance of 10.2 on a G4.
heck the 10.2.7 I heard it just was seeded for NON G5 users. This is NOT the OS that will do anything all that great on the G5.
so sorry to say it guys... but WE HAVE TO WAIT FOR PANTHER to be the fastest computer..
Don't forget the 1.8 had 2.something GB of RAM, that's plenty!
Also when Jobs did his G5 tests, did he run Panther or Smeagol?
I'm trying to do my best in digging up old threads to talk about my G5 (I promissed picture in another threat...picture which have been taking but I still haven't got on line yet). Hopefully the admins will appreciate that
Anyhow, I bought a stock 1.8 GHz G5 yesterday, so here are a few comments from less than 24 hours of work and play:
-the insides are very cool. I especially like how shinny the "G5" is on the heat sink. As an asside, I opened it up to put in an AirPort Extreme card and was amazed by how small it was. For some reason I was expecting something similar in size to a PC card.
-Classic boots up very very quickly. For reference, I'm coming from a 550 MHz TiBook with only 256 RAM. But, still, I've never seen a machine boot into OS 9 that fast even natively. I'd be curious to know how fast classic boots on the dual G4s. Actually, all of the apps feel quick. For example, Word boots up in a flash and then there is no lag in anything when using it, such as in opening contextual menus.
-OS X is good and snappy. Again, I don't know if it is because I now have double the RAM of what I had before, but it seems very very fast.
-As a nice treat, both iCal and iPhoto open fast and feel fast.
Thats all I can think of for now. As I use it more, I'll post again.
> What are you talking about? When I tell people that I'm getting a
> G5 (and I don't say "Powermac G5" or "Apple Powermac"-- just "G5"),
> people instantly know the product which I am refering to. The name
> recognition is awesome. People have seen the ad on TV, read the ad in
> magazines...people know "G5" as well as they do "iMac".
That's because Apple does some marketing in your local market. They do very little TV advertising in Europe and none here in li'l ol' Switzerland - strange because here Apple has the highest market share of any other country...
has anyone verified what this fellow is talking about?
Safari redraws horribly slow. On the other hand Finder windows redraw very quickly. So is the problem the OS or the App? It would seem to me that the problem is with the app and how it draws windows. Safari may not be programmed to resize very quickly? Why? perhaps because most of the time, most of the people set their window size in safari and don't change it. MAybe the finder works faster because it was programmed to be more responsive to user changes since the user would be more likely to change the window size to facilitate file searches and copies.
If this is correct then pulling a safari window around is a poor way to gauge system speed. Oddly, watching the cpu monitor, resizing safari and the finder provoked the same amount of CPU load, so clearly the CPU is NOT doing anything different when working with Safari vs. Finder. If this fellow wants to test out a DAW then he ought to go to a specialist with a setup that he wants and test it out. or may go over to a site about systems he uses and wait for people to test out a configuration like his to post thier experiences.
Oddly, watching the cpu monitor, resizing safari and the finder provoked the same amount of CPU load, so clearly the CPU is NOT doing anything different when working with Safari vs. Finder.
CPU "load" as reported by UNIX utilities like Top or CPU utilization as indicated in the CPU monitor should be near 100% whenever any computation is being done that takes longer than the monitor's time slice. What's relevant is how much longer than the time slice the computation takes, and the monitor won't tell you that.
I think the redraw in browsers is far more complicated than window resizing. Just a guess.
I mean, all that HTML coding that gets interpreted by the browser is a lot to handle, wouldn't you think?
Resizing the window dimensions seems like it wouldn't be so easy in Safari or IE as compared to resizing a window and having it's contents merely moved to fit the window instead.
And, while the HTML may be dynamic I'd assume it would take far longer to redraw and reinterpret the code than it would to reinterpret the spacing between Finder icons.
Maybe the simple answer is easier than the more complex one.
In that way maybe it IS a good test of proc speed. In other words, how fast can the proc "reinterpret" the HTML and redraw it in a Safari window.
And, regardless of whether Safari is coded to redraw quickly, all the "benchmarks" we've seen so far have been an unoptimized OS. So the argument stands the same.
I had my first 5 minutes on a 1.8 G5 the other day. I also found the scrolling of a CNN web page in Safari to be a bit choppy. The app also took like 3 bounce to launch. Didn't hav much else on the system to test it with. My feeling is that its all Smeagol's fault and things will look much better with Panther. No worries.
CPU "load" as reported by UNIX utilities like Top or CPU utilization as indicated in the CPU monitor should be near 100% whenever any computation is being done that takes longer than the monitor's time slice. What's relevant is how much longer than the time slice the computation takes, and the monitor won't tell you that.
-- Mark
but if you are spending a good 30 seconds resinzing a window you get a good readout (in the extended view) of how much the CPU is being utilized.
anyways. I was at the Apple Store at Tices Corner and they had a 1.8 with the sound editing app on. When it had all of it's windows open it was takign upto 65% of the CPU with the window manager taking up nearly the rest of the cpu time. however when it was minimized the cpu utilization dropped to about 10-15% even while it was still playing th tracks. So again I think performance really depends on what app and what specifically is being done. So the non techie here should find someone with a similar set up to what he will be doing and judge based on that.
Got the chance to play with a 1.8 G5 this afternoon. As always, Apple has done an amazing job in the industrial design department. The fit and finish is sleek and looks like a million bucks.
The mirrored G4 tower sitting next to it looked old and tired. It funny how I thought the same of the blue and white G3 when the G4's were introduced.
Yes, it was snappy running 10.2.7 and I didn't see any lag in scrolling or opening of windows. In fact, I don't even think there was one bounce when I launched into Safari...it just opened!
The fans were almost non existant in noise (mind you I wasn't putting the machine through anything intensive).
The only drawback I found was the noise of the combo drive. It's neat how the panel drops and a tray comes out. However, it sounded a bit too clackety and unrefined...even noiser than my FP iMac's tray.
Otherwise, for the five minutes or so i had with it, it looked like a winner.
That reminds of an interesting thing from ArsTechnica... apparently iTunes (at least when playing music) has a unique way of being "indestructible". Instead of using 'nice', iTunes seems to have a way of taking over the machines processor, getting even more power then -20 in 'nice'.
Yes, iTunes has a thread the is jacked up into the real-time band. This means if it needs the time, it pre-empts everything, even kernel-land tasks.
I'd like to see a reasoned response from someone who knows about why some apps tend to resize better than others on the same machine. I've noticed this, too.
[snip]
The smoothness appears to have something to do with the way individual apps are written as well as the OS.
Indeed it does. Essentially, it works like this. When the user starts resizing a window, the OS routines that handle window sizing take over, tracking the mouse as it moves.
When the user moves the mouse, the OS changes the size of the window, which is actually very speedy, and then calls the application to recalculate, and then redraw the window's buffer, then the window server flushes the display.
Applications that have a lot to recalculate/redraw, or do so inefficiently are slow when it comes to doing live resizing.
Windows XP does things a bit differently, in subtle ways. First, the application doesn't redraw each step of the resizing. Try resizing an IE window quickly under Windows XP, and you'll notice it waits a bit before it redraws. The window's contents aren't recalculated/redrawn with every movement of the mouse, just the window frame is.
Secondly, the windows on Windows XP are not double-buffered. When windows under Windows XP are redrawn, they are redrawn directly to the screen, the the primitives are hardware-accelerated.
Quartz's nature has many advantages, despite the slight inherent performance hit. As evidence to this, Windows will be moving to a imaging model similar to what MacOS X has... in 2005 (or 2006).
There's no reason why OS X couldn't do what Windows does in terms of redrawing the window contents only after the user isn't moving the mouse quickly anymore. It can be implemented now on an individual application basis, without much work, or it could be implemented on an OS level.
My guess is that this isn't being done because the goal for Aqua is smoothness and visual coherency. Window contents that don't redraw exactly with the window's size (even if the delay is slight) doesn't fit in with this model.
Oddly, watching the cpu monitor, resizing safari and the finder provoked the same amount of CPU load, so clearly the CPU is NOT doing anything different when working with Safari vs. Finder.
That's not exactly true. When resizing a window, it resizes more smoothly/quickly in the Finder than in Safari, yes? That's because it is redrawing the window more often, which it can do because the window is recalculated/redrawn faster in the Finder than in Safari.
In both cases, the CPU is maxed out, but the reason it is maxed out in Safari with its "slow" resizing and also in the Finder with its "fast" resizing is that they are both redrawing the resized contents as fast as they can.
If the GUI feels less responsive to a novice, it is. It should be ok to notice this without being blasted for not appreciating the reasons.
Nobody blasted anybody in this thread. Discussion of the reasons is just to emphasize that it's the result of a tradeoff that provides value in a different place.
That said, the rumor is that 10.3 is much better in this regard.
As for the poster who asked why different applications resize more or less quickly, it comes down to how the application's redrawing of the resized window is designed. Resizing in Safari is slow because it has to reformat all the visible HTML for every update. In the Finder it's not so bad because the contents of a window do not get reorganized or reflowed when the window size changes.
Of course there are efficient (Finder) and inefficient (iTunes) ways to do the same thing, and it's all about where the developer put their effort. Incidentally, window redraws are entirely an application problem. This is true in OS 9 as well, and you'll see the same kind of lag in many applications.
Comments
Originally posted by Mac Voyer
Hello all,
I went to THE MAC STORE today and got my hands on a 1.6 and 1.8 G5. Let me just say that I did no benchmarks, nor do I have any intentions of doing any benchmarks so please do not ask. I think that they are rather silly for the most part. I was interested in performance, however. I am thinking about getting a more powerful machine to resurrect my DAW. I have a friend there and we spend quite a bit of time talking Mac. Frankly, I was a little disappointed with what I saw. My unofficial test for Mac performance is scrolling a long document. When you move the slider, the document should move exactly with the pointer no matter how fast you move it. This is true in OS 9 and Windows. It demonstrates how the OS feels, QE and all that. Well, it did not do all that well. There are no miracles here folks. I know this is just one element of the GUI, but this is what OS X is based on. Yes, yes, I already know about the expected improvements in Panther. I grow a little tired of waiting for software solutions for performance deficiencies.
It could be said that my tests of the 1.8 were a bit unfair because it was encoding MP3s at the time. The CPU meter showed 100% usage. On this machine, I tried iSight for the first time. I was not impressed. The image was quite choppy. The salesman said that it was because the processor was under load. I hooked the iSight up to my iBook and it was still choppy and the salesman said that it was because it was a G3. He promised that the iSight really worked better than was he was able to demonstrate at the time. I will just have to take him at his word. It is quite possible that the dual 2 will be able to handle a processor intensive task and something else without taking a big performance hit. I hope so. But for those who believe that the G5 is the end all to all of Apple's performance issues, IT IS NOT! There is no magic here people so don't drink too deeply of the Kool-Aid.
The architecture may in fact lead to revolutionary performance gains. But the current iteration of the SP G5 is evolutionary at best. I would love to see the real world performance of a dual G4 in comparison. I do not have hands on experience with G4 towers. I never had an interest in them until now. My experience with the 1.6 and 1.8 really made me think that duals are the only way to go for the Mac. I will also acknowledge that either machine would probably be sufficient for audio work I would hope that running 16 stereo tracks with two or three filters per track would not bring the system to its knees. But after the demo I had in the store today, I'm not so sure.
There were some things I liked, the design is nice, though it is really big in person. You can feel a pocket of cool air in the front of the machine and warm air blowing out of the back. I heard the fans going at full blast and it was not that bad. By the way, the air coming from the back was not very hot at all. Good job, Apple. Menus were snappier than I was used to. But remember, I have an iBook.
My conclusion, this may be a very good, if not expensive upgrade for people with a low end Macs. Certain pro tasks may see a nice speed bump in specifically optimized programs. I do not know what kind of improvement it represents for general computing. I still use my PC for heavy lifting. (I am not a PS user.) This is not a slash and burn review. This is not a review. It is the first impression of a not overly technical guy that loves computers on any platform and who happens to be in the market for his next tower. Please don't bog this thread down with benchmarks. Try to keep the discussion in layman's terms. If there is no discussion, that's OK too. I hope this post is helpful to someone.
Cheers.
Are you sure [about the scrolling]? Even on my "weak" 900Mhz iBook, scrolling is pretty good. The scrollbar seems to lag more than the scrolling.
Originally posted by Gee4orce
so what you are saying is that you want iTunes to NOT use 100% of the CPU (and therefore cripple it's own performance) ? Well, if that's what you want, then you can use Unix's 'nice' command, to lower the process priority.
I don't think I've ever seen text not keep up with the scroll bars, except in something like Hydra with syntax colouring turned on and a very long document.
You really didn't give the G5 or the iSight a fair chance. Go back, turn off iTunes, and I think you'll be impressed.
...and yes, I know you don't want to hear this, but Panther really does make a huge difference.
That reminds of an interesting thing from ArsTechnica... apparently iTunes (at least when playing music) has a unique way of being "indestructible". Instead of using 'nice', iTunes seems to have a way of taking over the machines processor, getting even more power then -20 in 'nice'.
Originally posted by Brad
10.2.7, aka Smeagol, on the G5 can be considered a "hack job", FYI. It's just a quick fix to get the OS to *run* on the new processor. It is very un-optimized for the G5 and uses the old compiler that's designed for the G3s and G4s. It was stated months ago that Smeagol would be slow and would make the G5 look slower than it really is.
Panther is the OS that is *meant* for this machine not just because it offers performance gains across the board but also because it uses the updated gcc. Panther will make the G5 fly compared to Smeagol.
Has anyone tried Panther beta on a G5?
Originally posted by Wireless
Don't get any ideas yet guys.... The G5 will be VERY VERY good, but not yet! we need panther. also the 256MB of ram probly isn't that great for the curent OS X
10.2.7 witch is NOT made for the G5 it doesn't take advantage of ANY of the G5 features.
There ONLY goal for 10.2.7 is to let it run with onpar preformance of 10.2 on a G4.
heck the 10.2.7 I heard it just was seeded for NON G5 users. This is NOT the OS that will do anything all that great on the G5.
so sorry to say it guys... but WE HAVE TO WAIT FOR PANTHER to be the fastest computer..
Don't forget the 1.8 had 2.something GB of RAM, that's plenty!
Also when Jobs did his G5 tests, did he run Panther or Smeagol?
Anyhow, I bought a stock 1.8 GHz G5 yesterday, so here are a few comments from less than 24 hours of work and play:
-the insides are very cool. I especially like how shinny the "G5" is on the heat sink. As an asside, I opened it up to put in an AirPort Extreme card and was amazed by how small it was. For some reason I was expecting something similar in size to a PC card.
-Classic boots up very very quickly. For reference, I'm coming from a 550 MHz TiBook with only 256 RAM. But, still, I've never seen a machine boot into OS 9 that fast even natively. I'd be curious to know how fast classic boots on the dual G4s. Actually, all of the apps feel quick. For example, Word boots up in a flash and then there is no lag in anything when using it, such as in opening contextual menus.
-OS X is good and snappy. Again, I don't know if it is because I now have double the RAM of what I had before, but it seems very very fast.
-As a nice treat, both iCal and iPhoto open fast and feel fast.
Thats all I can think of for now. As I use it more, I'll post again.
> G5 (and I don't say "Powermac G5" or "Apple Powermac"-- just "G5"),
> people instantly know the product which I am refering to. The name
> recognition is awesome. People have seen the ad on TV, read the ad in
> magazines...people know "G5" as well as they do "iMac".
That's because Apple does some marketing in your local market. They do very little TV advertising in Europe and none here in li'l ol' Switzerland - strange because here Apple has the highest market share of any other country...
Safari redraws horribly slow. On the other hand Finder windows redraw very quickly. So is the problem the OS or the App? It would seem to me that the problem is with the app and how it draws windows. Safari may not be programmed to resize very quickly? Why? perhaps because most of the time, most of the people set their window size in safari and don't change it. MAybe the finder works faster because it was programmed to be more responsive to user changes since the user would be more likely to change the window size to facilitate file searches and copies.
If this is correct then pulling a safari window around is a poor way to gauge system speed. Oddly, watching the cpu monitor, resizing safari and the finder provoked the same amount of CPU load, so clearly the CPU is NOT doing anything different when working with Safari vs. Finder. If this fellow wants to test out a DAW then he ought to go to a specialist with a setup that he wants and test it out. or may go over to a site about systems he uses and wait for people to test out a configuration like his to post thier experiences.
Originally posted by Sondjata
Oddly, watching the cpu monitor, resizing safari and the finder provoked the same amount of CPU load, so clearly the CPU is NOT doing anything different when working with Safari vs. Finder.
CPU "load" as reported by UNIX utilities like Top or CPU utilization as indicated in the CPU monitor should be near 100% whenever any computation is being done that takes longer than the monitor's time slice. What's relevant is how much longer than the time slice the computation takes, and the monitor won't tell you that.
-- Mark
I mean, all that HTML coding that gets interpreted by the browser is a lot to handle, wouldn't you think?
Resizing the window dimensions seems like it wouldn't be so easy in Safari or IE as compared to resizing a window and having it's contents merely moved to fit the window instead.
And, while the HTML may be dynamic I'd assume it would take far longer to redraw and reinterpret the code than it would to reinterpret the spacing between Finder icons.
Maybe the simple answer is easier than the more complex one.
In that way maybe it IS a good test of proc speed. In other words, how fast can the proc "reinterpret" the HTML and redraw it in a Safari window.
And, regardless of whether Safari is coded to redraw quickly, all the "benchmarks" we've seen so far have been an unoptimized OS. So the argument stands the same.
Originally posted by mark_wilkins
CPU "load" as reported by UNIX utilities like Top or CPU utilization as indicated in the CPU monitor should be near 100% whenever any computation is being done that takes longer than the monitor's time slice. What's relevant is how much longer than the time slice the computation takes, and the monitor won't tell you that.
-- Mark
but if you are spending a good 30 seconds resinzing a window you get a good readout (in the extended view) of how much the CPU is being utilized.
anyways. I was at the Apple Store at Tices Corner and they had a 1.8 with the sound editing app on. When it had all of it's windows open it was takign upto 65% of the CPU with the window manager taking up nearly the rest of the cpu time. however when it was minimized the cpu utilization dropped to about 10-15% even while it was still playing th tracks. So again I think performance really depends on what app and what specifically is being done. So the non techie here should find someone with a similar set up to what he will be doing and judge based on that.
The 1.8 does have a bit more snap out of the box. The stock ram configurations are certainly a factor. Added an extra gig (2 sticks 512 PC3200).
The 1.8 comes with the Pioneer DVR-106D drive instead of the Sony in the 1.6 machine.
Maybe its me but the tray action on this Pioneer drive seems a bit quieter and smoother than on the Sony drive.
The hardrive looks to be a Seagate, just like on the 1.6.
The 1.8 comes with the Pioneer DVR-106D drive instead of the Sony in the 1.6 machine.
This seems to vary by machine; my 1.8 reports having the Sony drive.
The mirrored G4 tower sitting next to it looked old and tired. It funny how I thought the same of the blue and white G3 when the G4's were introduced.
Yes, it was snappy running 10.2.7 and I didn't see any lag in scrolling or opening of windows. In fact, I don't even think there was one bounce when I launched into Safari...it just opened!
The fans were almost non existant in noise (mind you I wasn't putting the machine through anything intensive).
The only drawback I found was the noise of the combo drive. It's neat how the panel drops and a tray comes out. However, it sounded a bit too clackety and unrefined...even noiser than my FP iMac's tray.
Otherwise, for the five minutes or so i had with it, it looked like a winner.
Originally posted by ryaxnb
That reminds of an interesting thing from ArsTechnica... apparently iTunes (at least when playing music) has a unique way of being "indestructible". Instead of using 'nice', iTunes seems to have a way of taking over the machines processor, getting even more power then -20 in 'nice'.
Yes, iTunes has a thread the is jacked up into the real-time band. This means if it needs the time, it pre-empts everything, even kernel-land tasks.
Originally posted by moki
Yes, iTunes has a thread the is jacked up into the real-time band. This means if it needs the time, it pre-empts everything, even kernel-land tasks.
Is there a documented API for doing this someplace?
Originally posted by chris v
I'd like to see a reasoned response from someone who knows about why some apps tend to resize better than others on the same machine. I've noticed this, too.
[snip]
The smoothness appears to have something to do with the way individual apps are written as well as the OS.
Indeed it does. Essentially, it works like this. When the user starts resizing a window, the OS routines that handle window sizing take over, tracking the mouse as it moves.
When the user moves the mouse, the OS changes the size of the window, which is actually very speedy, and then calls the application to recalculate, and then redraw the window's buffer, then the window server flushes the display.
Applications that have a lot to recalculate/redraw, or do so inefficiently are slow when it comes to doing live resizing.
Windows XP does things a bit differently, in subtle ways. First, the application doesn't redraw each step of the resizing. Try resizing an IE window quickly under Windows XP, and you'll notice it waits a bit before it redraws. The window's contents aren't recalculated/redrawn with every movement of the mouse, just the window frame is.
Secondly, the windows on Windows XP are not double-buffered. When windows under Windows XP are redrawn, they are redrawn directly to the screen, the the primitives are hardware-accelerated.
Quartz's nature has many advantages, despite the slight inherent performance hit. As evidence to this, Windows will be moving to a imaging model similar to what MacOS X has... in 2005 (or 2006).
There's no reason why OS X couldn't do what Windows does in terms of redrawing the window contents only after the user isn't moving the mouse quickly anymore. It can be implemented now on an individual application basis, without much work, or it could be implemented on an OS level.
My guess is that this isn't being done because the goal for Aqua is smoothness and visual coherency. Window contents that don't redraw exactly with the window's size (even if the delay is slight) doesn't fit in with this model.
Originally posted by JBL
Is there a documented API for doing this someplace?
Sure. Look at the Mach headers/APIs. The scheduler is actually a bit of a mess, with several ways for accomplishing the same thing.
Originally posted by Sondjata
Oddly, watching the cpu monitor, resizing safari and the finder provoked the same amount of CPU load, so clearly the CPU is NOT doing anything different when working with Safari vs. Finder.
That's not exactly true. When resizing a window, it resizes more smoothly/quickly in the Finder than in Safari, yes? That's because it is redrawing the window more often, which it can do because the window is recalculated/redrawn faster in the Finder than in Safari.
In both cases, the CPU is maxed out, but the reason it is maxed out in Safari with its "slow" resizing and also in the Finder with its "fast" resizing is that they are both redrawing the resized contents as fast as they can.
Originally posted by reynard
If the GUI feels less responsive to a novice, it is. It should be ok to notice this without being blasted for not appreciating the reasons.
Nobody blasted anybody in this thread. Discussion of the reasons is just to emphasize that it's the result of a tradeoff that provides value in a different place.
That said, the rumor is that 10.3 is much better in this regard.
As for the poster who asked why different applications resize more or less quickly, it comes down to how the application's redrawing of the resized window is designed. Resizing in Safari is slow because it has to reformat all the visible HTML for every update. In the Finder it's not so bad because the contents of a window do not get reorganized or reflowed when the window size changes.
Of course there are efficient (Finder) and inefficient (iTunes) ways to do the same thing, and it's all about where the developer put their effort. Incidentally, window redraws are entirely an application problem. This is true in OS 9 as well, and you'll see the same kind of lag in many applications.
-- Mark