No shit! How are you going to cache contents of a page when the contents are chaning?
Well... in modern display model... like OS X, each window gets its own dedicated bit of memory. A bitmap, which stores the pixels belonging to the window. This works even when the contents are "chaning".
When windows overlap, in OSX they really are overlaping - there is stuff on the window that is covered up. You can see this in Expose - when all the windows are resized - without any work from the Apps themselves.
In XP when windows overlap - the covered-up portion of the window is lost and needs to be re-drawn when the trashed area is revealed.
The XP way can sometimes be more efficient - because at any one time there is only one screenful of pixels to manage. However the XP gets ugly when there are a lot of windows receiving a lot of redraw messages . In XP, each partially obscured window needs to be asked to do its own re-draws. So moving a window a few pixels can end up forcing a one or more big apps to be re-loaded from the page file.
There are pro and cons - but speaking for myself, the OS X method is massively more elegant and does not leave crap all over the display. Like the white paint trail that happens with the Google Earth example.
Mac OS X has had silky-smooth window MOVING since the public beta. This is because just about any GPU can do simple translation of pixels very fast. And with OS X's double-buffering, apps do not have to redraw anything - that is taken care of by the compositor in the Window Server.
Now when it comes to window RESIZING, it remains to be seen where the slowdown is. I have yet to see an explanation that makes sense to me. Note that when resizing, the CPU does not go to 100%, but the window resize widget in the lower right corner still cannot keep up with the mouse cursor. Is this still a matter of not enough GPU horsepower? Is it too much bloated nested subroutine calls in Cocoa to draw views, tables, cells, etc? I sure as hell can't figure it out. And none of the Apple engineers at WWDC ever talk about it either.
This link has a simulation-animation that demonstrates what we are talking about regarding the sluggishness of Mac OS X versus Windows in resizing windows.
[B]Well... in modern display model... like OS X, each window gets its own dedicated bit of memory. A bitmap, which stores the pixels belonging to the window. This works even when the contents are "chaning".
You still need to redraw the contents of the window because human eyes can't see what's inside of memory. They only see what's on the display.
BTW, Windows NT based systems (from version 1.0), btw, store the window information also in a separate memory space.
Quote:
In XP when windows overlap - the covered-up portion of the window is lost and needs to be re-drawn when the trashed area is revealed.
Sure, but why would you want to redraw the area that you can't see? That is not efficient.
[quote]
However the XP gets ugly when there are a lot of windows receiving a lot of redraw messages . In XP, each partially obscured window needs to be asked to do its own re-draws. So moving a window a few pixels can end up forcing a one or more big apps to be re-loaded from the page file.
[quote]
That is a function of hardware, not a function of OS. If OSX doesn't have enough ram to cache the windows, it will also go to page file to redraw. Where else will it go?
I have seen this on older machines, but the newer ones with 512+ MB of RAM don't have that problem.
Quote:
There are pro and cons - but speaking for myself, the OS X method is massively more elegant and does not leave crap all over the display. Like the white paint trail that happens with the Google Earth example.
As I said before, I have never seen this on my desktop with 1 GB of RAM, P4 Northwood 533 FSB 2.4 GHz, Ati 9600 XT 128 MB 3 year old PC. Nor have I seen this on my Fujitsu P7010D with 1.1 GHZ Pentium M Banias core with Intel Extreme 2 GFX and 768 MB of memory.
I have seen this on machines with 256 MB of memory and lots of windows open. However, I have also seen this on a G4 mac with 256 MB of ram running OSX 10.3.8.
And there is always someone who says this. Well, it ain't as smooth as that Windows animation I posted the link to, on my dual G5.
Are you saying that your iMac resizes like the rightmost animation (the Windows one)? The arrow cursor never can be pulled off the resize widget in the corner of the window?
It's the repositionning and redrawing of elements inside the window that causes the slow down.
Ever wonder why TextEdit and Preview windows resize extremely fast (instantaneously) and iCal, Mail and Safari resize extremely slow?
Everything is dynamically resized every in sync with the window. In the case of TextEdit, there's just not much to resize...only text. In the case of Preview, OS X is essentially just cropping the image.
iCal and Mail (like many multipane interfaces) on the other hand have many elements inside their windows. Mail and Safari must also dynamically resize HTML. You'll notice that Safari windows resizes much faster if a website was coded with absolute positions instead of centering the content or allowing the content to resize itself to the window width.
This isn't rocketscience. But it seems like all of you are still in gradeschool so it's understandable that you don't get it.
Now if we contrast the way things work in OS X with Windows, you'll notice that (in a situation when things need to be resized and not just cropped) the content inside Windows windows doesn't actually refresh in sync with the resizing. It gets cropped (or flickers wildly skipping some redraws) and then eventually resizes itself to the size of the window.
And there is always someone who says this. Well, it ain't as smooth as that Windows animation I posted the link to, on my dual G5.
Are you saying that your iMac resizes like the rightmost animation (the Windows one)? The arrow cursor never can be pulled off the resize widget in the corner of the window?
Yup, that's what I'm saying. I've only tried this in Safari though. Resizing a window really fast to see if I can make the pointer go faster than the window isn't something I normally do
It certainly resizes these forums better than my PC here at work.
It's a 2.66 Ghz Celeron with 512 Ram using Firefox.
Comments
Originally posted by skatman
No shit! How are you going to cache contents of a page when the contents are chaning?
Well... in modern display model... like OS X, each window gets its own dedicated bit of memory. A bitmap, which stores the pixels belonging to the window. This works even when the contents are "chaning".
When windows overlap, in OSX they really are overlaping - there is stuff on the window that is covered up. You can see this in Expose - when all the windows are resized - without any work from the Apps themselves.
In XP when windows overlap - the covered-up portion of the window is lost and needs to be re-drawn when the trashed area is revealed.
The XP way can sometimes be more efficient - because at any one time there is only one screenful of pixels to manage. However the XP gets ugly when there are a lot of windows receiving a lot of redraw messages . In XP, each partially obscured window needs to be asked to do its own re-draws. So moving a window a few pixels can end up forcing a one or more big apps to be re-loaded from the page file.
There are pro and cons - but speaking for myself, the OS X method is massively more elegant and does not leave crap all over the display. Like the white paint trail that happens with the Google Earth example.
C.
Now when it comes to window RESIZING, it remains to be seen where the slowdown is. I have yet to see an explanation that makes sense to me. Note that when resizing, the CPU does not go to 100%, but the window resize widget in the lower right corner still cannot keep up with the mouse cursor. Is this still a matter of not enough GPU horsepower? Is it too much bloated nested subroutine calls in Cocoa to draw views, tables, cells, etc? I sure as hell can't figure it out. And none of the Apple engineers at WWDC ever talk about it either.
This link has a simulation-animation that demonstrates what we are talking about regarding the sluggishness of Mac OS X versus Windows in resizing windows.
http://www.xvsxp.com/general/#moveResize
Is there someone out there that wins money resizing windows and moving them around?
Once window resizing is smooth, people will have nothing else to talk about...boo hoo hoo.
Originally posted by Carniphage
[B]Well... in modern display model... like OS X, each window gets its own dedicated bit of memory. A bitmap, which stores the pixels belonging to the window. This works even when the contents are "chaning".
You still need to redraw the contents of the window because human eyes can't see what's inside of memory. They only see what's on the display.
BTW, Windows NT based systems (from version 1.0), btw, store the window information also in a separate memory space.
In XP when windows overlap - the covered-up portion of the window is lost and needs to be re-drawn when the trashed area is revealed.
Sure, but why would you want to redraw the area that you can't see? That is not efficient.
[quote]
However the XP gets ugly when there are a lot of windows receiving a lot of redraw messages . In XP, each partially obscured window needs to be asked to do its own re-draws. So moving a window a few pixels can end up forcing a one or more big apps to be re-loaded from the page file.
[quote]
That is a function of hardware, not a function of OS. If OSX doesn't have enough ram to cache the windows, it will also go to page file to redraw. Where else will it go?
I have seen this on older machines, but the newer ones with 512+ MB of RAM don't have that problem.
There are pro and cons - but speaking for myself, the OS X method is massively more elegant and does not leave crap all over the display. Like the white paint trail that happens with the Google Earth example.
As I said before, I have never seen this on my desktop with 1 GB of RAM, P4 Northwood 533 FSB 2.4 GHz, Ati 9600 XT 128 MB 3 year old PC. Nor have I seen this on my Fujitsu P7010D with 1.1 GHZ Pentium M Banias core with Intel Extreme 2 GFX and 768 MB of memory.
I have seen this on machines with 256 MB of memory and lots of windows open. However, I have also seen this on a G4 mac with 256 MB of ram running OSX 10.3.8.
Originally posted by kim kap sol
When will this fucking subject be put to rest?! It's been 5 years now and still a lot of people got surprised look on their face.
It will be put to rest when one or both of 2 things happen:
1) Somebody can explain what the basis of the slowdown is.
2) The slowdown is eliminated.
Quote:
Is there someone out there that wins money resizing windows and moving them around?
It usually takes about 15 posts for someone to say this. The answer is: it's irrelevant.
Quote:
Once window resizing is smooth, people will have nothing else to talk about...boo hoo hoo.
Explain the cause of the slowdown then. Please.
Originally posted by Flounder
Window resizing is smooth as silk on my new iMac
And there is always someone who says this. Well, it ain't as smooth as that Windows animation I posted the link to, on my dual G5.
Are you saying that your iMac resizes like the rightmost animation (the Windows one)? The arrow cursor never can be pulled off the resize widget in the corner of the window?
Originally posted by lundy
Explain the cause of the slowdown then. Please.
It's the repositionning and redrawing of elements inside the window that causes the slow down.
Ever wonder why TextEdit and Preview windows resize extremely fast (instantaneously) and iCal, Mail and Safari resize extremely slow?
Everything is dynamically resized every in sync with the window. In the case of TextEdit, there's just not much to resize...only text. In the case of Preview, OS X is essentially just cropping the image.
iCal and Mail (like many multipane interfaces) on the other hand have many elements inside their windows. Mail and Safari must also dynamically resize HTML. You'll notice that Safari windows resizes much faster if a website was coded with absolute positions instead of centering the content or allowing the content to resize itself to the window width.
This isn't rocketscience. But it seems like all of you are still in gradeschool so it's understandable that you don't get it.
Now if we contrast the way things work in OS X with Windows, you'll notice that (in a situation when things need to be resized and not just cropped) the content inside Windows windows doesn't actually refresh in sync with the resizing. It gets cropped (or flickers wildly skipping some redraws) and then eventually resizes itself to the size of the window.
Do you need any more questions answered?
Originally posted by lundy
And there is always someone who says this. Well, it ain't as smooth as that Windows animation I posted the link to, on my dual G5.
Are you saying that your iMac resizes like the rightmost animation (the Windows one)? The arrow cursor never can be pulled off the resize widget in the corner of the window?
Yup, that's what I'm saying. I've only tried this in Safari though. Resizing a window really fast to see if I can make the pointer go faster than the window isn't something I normally do
It certainly resizes these forums better than my PC here at work.
It's a 2.66 Ghz Celeron with 512 Ram using Firefox.