window resizing (split from "panther requests")
Quote:
Originally posted by 123
You have to activate the target window, then the file will become visible (just as in Jaguar).
Also a bit disappointing: moving windows around still uses lots of processing power, I don't really know why... However, I have to say that the overall responsiveness/speed really has been improved dramatically. It's just resizing (without much rendering) and movement that use too much resources in my opinion.
Originally posted by 123
You have to activate the target window, then the file will become visible (just as in Jaguar).
Also a bit disappointing: moving windows around still uses lots of processing power, I don't really know why... However, I have to say that the overall responsiveness/speed really has been improved dramatically. It's just resizing (without much rendering) and movement that use too much resources in my opinion.
How much processing utilization do you consider "lots?" Quickly dragging a window around on my iBook (with Jaguar) takes around 30-34% of the CPU. I've never had a problem with window dragging -- it's always been great in OS X.
Another post concerning slow window resizing is distressing, though. The poster claims it's as bad as it was with 10.0, which is amazingly poor. Let's hope the future developer leaks have better performance in this regard.
Comments
Originally posted by Big Mac
How much processing utilization do you consider "lots?" Quickly dragging a window around on my iBook (with Jaguar) takes around 30-34% of the CPU. I've never had a problem with window dragging -- it's always been great in OS X.
Another post concerning slow window resizing is distressing, though. The poster claims it's as bad as it was with 10.0, which is amazingly poor. Let's hope the future developer leaks have better performance in this regard.
Well, you're REALLY not gonna like this then - I sat down to goof around with one of the 40 Dual 2.0 G5s this morning at the optimization lab at WWDC. The window resizing was definitely smoother than my dual 1 gig G4, but the cursor still is easy to get ahead of the window corner ( OS X Jag 10.2.7 "Smeagol" build, 2 GB of RAM).
I think the OS needed rebooting, though, because it took 32 bounces to launch Safari. These G5 were getting hammered all day with beta applications and alpha kernel extensions.
There is no way that dual 2gHz G5s could have any trouble recalculating a window contents. I think there are some delay loops or locks or redraw frequencies keeping this from being real-time. In the CHUD presentation on Wednesday, I noticed that the split-window dragging (as the Mail.app has) was a bit sluggish on the speaker's G5 as he split a window in xCode.
Anybody know how this could be?
Originally posted by lundy
Anybody know how this could be?
yup - for textured windows: procedural textures rendered by the CPU over the system bus into ram, from there copied over AGP to the GFX card, from there blitted to the screen (not to mention all of the GUI bitmaps for widgets...). for regular aqua windows the same is true, but instead of a metal procedural texture, a lines bitmap is used... I don't care what mac you have, making the cpu draw is poor graphics subsystem design, and using bitmaps for the entire UI takes poor advantage of available hardware primitives... I've used panther, but not on a G5, and not with QE, so I don't know how much better its going to get...
Originally posted by grad student
yup - for textured windows: procedural textures rendered by the CPU over the system bus into ram, from there copied over AGP to the GFX card, from there blitted to the screen (not to mention all of the GUI bitmaps for widgets...). for regular aqua windows the same is true, but instead of a metal procedural texture, a lines bitmap is used... I don't care what mac you have, making the cpu draw is poor graphics subsystem design, and using bitmaps for the entire UI takes poor advantage of available hardware primitives... I've used panther, but not on a G5, and not with QE, so I don't know how much better its going to get...
An update - I got home and installed Panther. This thing screams on my dual 1 gHz G4. About 3-4 times as fast as Jagwyre in general UI and system tasks. Preview.app is so fast it couldn't get any faster. Panther is way faster on the G4 than Smeagol was on the dual G5.
So I'm thinking that Smeagol is definitely not appropriate for the G5 if one is going to look at performance. I'd keep this in mind when looking at machines in the stores after release.
Originally posted by lundy
Well, you're REALLY not gonna like this then - I sat down to goof around with one of the 40 Dual 2.0 G5s this morning at the optimization lab at WWDC. The window resizing was definitely smoother than my dual 1 gig G4, but the cursor still is easy to get ahead of the window corner ( OS X Jag 10.2.7 "Smeagol" build, 2 GB of RAM).
I think the OS needed rebooting, though, because it took 32 bounces to launch Safari. These G5 were getting hammered all day with beta applications and alpha kernel extensions.
There is no way that dual 2gHz G5s could have any trouble recalculating a window contents. I think there are some delay loops or locks or redraw frequencies keeping this from being real-time. In the CHUD presentation on Wednesday, I noticed that the split-window dragging (as the Mail.app has) was a bit sluggish on the speaker's G5 as he split a window in xCode.
Anybody know how this could be?
That isn't very positive at all. I don't understand how such fast machines can be brought to their knees by window resizing. If it's not totally smooth on any G5 (let alone a 2GHz), then Apple should simply give up. Take the live resizing away, please. It helps no one if it's pathetically slow and not even much faster CPUs can [edit: typo] cure the problem.
Originally posted by Big Mac
That isn't very positive at all. I don't understand how such fast machines can be brought to their knees by window resizing. If it's not totally smooth on any G5 (let alone a 2GHz), then Apple should simply give up. Take the live resizing away, please. It helps no one if it's pathetically slow and not even much faster CPUs can't cure the problem.
Because there will always be people saying "My resizing is fine", or "well, if all you do all day is resize windows...", I just want to demonstrate what I mean by this.
See how the cursor in this picture is way up by the "pm" button, between the "profile" and "search" buttons? I grabbed the resizing handle in the lower right corner of the window and dragged it as fast as possible up and to the left. It was dragging the resizing handle really fast and I took a SnapZ screenshot to freeze it in mid-resize. Look how far away from the resize corner the cursor is. That is how you are able to "outrun" the live resizing with the cursor, and this is "only" a dual 1.0 gHz G4 running Panther Preview (it's worse on Jagwyre 10.2.6). On a G3, it's three or four seconds sometimes before the machine can catch up. And that's if you don't get a spinning rainbow cursor.
Now on BeOs or shudder, Windoze, even years ago, you could not drag the cursor off the corner like that - the window would follow it fast enough.
To see an example of this, move a window back and forth rapidly by grabbing the title bar - you can't get the cursor ahead of where it is placed because the window CAN keep up (due to the hardware helping out).
So I would love to hear from some systems programmers on how this could POSSIBLY still be a problem in a dual G5. There is just no way that a total of 4 gHz of power isn't enough to recompute the contents of a window on the fly. There has to be code somewhere that is saying, "Only recompute this window every (...) milliseconds, or something like that.
Originally posted by lundy
So I would love to hear from some systems programmers on how this could POSSIBLY still be a problem in a dual G5. There is just no way that a total of 4 gHz of power isn't enough to recompute the contents of a window on the fly. There has to be code somewhere that is saying, "Only recompute this window every (...) milliseconds, or something like that.
Well, it doesn't address the problem wrt to the hardware, but unlike all of the other window actions (moving, minimizing, etc.) live resize requires that the OS ask the app to redraw the window - it can't act on it's own.
In the case of the other actions, OS X can take the window backing store and just go to town on it. If the window is updating, OS X doesn't care, it just works with what gets passed out, so movies keep playing, etc.
My guess is that the inefficiency lies in the communication back to the app and the app having to redraw all contents based on the new window width. (And a long forum window in a browser with a lot of text is probably a fairly difficult case if it's using an advanced line composer dealing with word wrapping, hyphenation, and the like). Panther should include a lot of these types of optimizations, so I'd look to that rather than the G5 for your answer.
Originally posted by johnsonwax
Well, it doesn't address the problem wrt to the hardware, but unlike all of the other window actions (moving, minimizing, etc.) live resize requires that the OS ask the app to redraw the window - it can't act on it's own.
In the case of the other actions, OS X can take the window backing store and just go to town on it. If the window is updating, OS X doesn't care, it just works with what gets passed out, so movies keep playing, etc.
My guess is that the inefficiency lies in the communication back to the app and the app having to redraw all contents based on the new window width. (And a long forum window in a browser with a lot of text is probably a fairly difficult case if it's using an advanced line composer dealing with word wrapping, hyphenation, and the like). Panther should include a lot of these types of optimizations, so I'd look to that rather than the G5 for your answer.
I appreciate that response. . . and I hate to drag down this thread with negativity, but I think it's high time we demand more from Apple. Here are the possible solutions:
A) Cut the crap and make it fast already! If this feature is to be preserved, Apple must do whatever it has to in order to speed up the operation. I know that applications attempt to reposition objects while resizing; if that's the culprit, clip the window instead. Clip the content while the mouse button is down and only resize after the button is no longer down. (Isn't that how Windows does it?)
It's either A or B. Please, Apple, please.
Originally posted by johnsonwax
Well, it doesn't address the problem wrt to the hardware, but unlike all of the other window actions (moving, minimizing, etc.) live resize requires that the OS ask the app to redraw the window - it can't act on it's own.
That's true but the brushed metal apps are from Apple and the Finder is even part of the OS. It's their responisbility to optimize these apps.
I understand that html-rendering can be computational intensive, live resizing of browser windows is excusable (although ie for Windows does it much better).
But now have a look at itunes and do some resizing, it's slow even though almost nothing has to be rendered. The left pane with the play lists always stays the same, the only thing that has to be done there is rectangular clipping. The same applies to the panes on the right (overview mode), the content stays the same and is just clipped. The artist and album title bars have to be resized but you just have to add more of that gradient bar you already have stored somewhere, the text itself doesn't need to be written again. The scrollbars can be composed of a few 2D elements, not much computation there since most of the time only the one at the bottom is updated anyway. Which leaves us with the horizontal brushed metal bars. There's different lighting and also text has to be newly written on top of the bars every time you resize the window, this could indeed take some time. However, 20-40 frames per second should easily be possible if this is optimized... and I'm sure it's not (Which apps can be made metal free? One could time resizing with and without metal). I'm quite sure the content of the panes is rendered again and again even if it stays exactly the same and a lot of unnecessary computations are done and slow everything down.
In short, it appears that window resizing is one of the most complicated events in Mac OS X because it involves almost every part of its underlying structure. Of course, optimizing low-level stuff will help it a lot, I'm just not sure about how much it can still be optimized.
I can't say how it works in Windows, but one thing is certain: ObjC is currently very slow compared to C++ which, in turn, is slow compared to C in what concerns sending messages. If you have to send several thousands of messages every time a window is resized by one pixel, you know what happens.
Originally posted by 123:
Like what? Take a look at itunes and explain me what needs to be redrawn except the brushed metal stuff they could easily turn off.
1. My iTunes window has 4 list views (in the browser mode), the top view with the timer/frequency-amplitude graph. It has texture, 3 standard semaphore widgets and 1 standard resize widget. It has a translucent shadow.
2. Each of the list views is NSTableView. NSTableViews work with data sources, that is, there are several methods you define which get called for every NSCell in the view. NSCell is the intersection of a column and a row in an NSTableView. The song list in my config has 6 columns and 15 rows, plus the header. It amounts to approximately > 100 NSCells.
3. Every time you resize the window by 1 pixel, you get at least 3 application-wide notifications sent one after another. They are slow. Much slower than just calling a function in C.
4. For every live resize cycle the graphic subsystem draws > 100 NSCells, each of which contains anti-aliased text, which may generally reflow. The text has to be laid out and anti-aliased again.
5. The top view changes its position and has to be drawn again. So is the window title.
All this is drawn into the window's backing store. AFAIK, none of these can be done in a graphic accelerator. The CPU is busy laying out Unicode glyphs in a sophisticated manner and smoothing their shape, drawing NSCells' interior, calculating their relative sizes, etc.
6. Compositing all this stuff is reasonably fast if you have Quartz Extreme. To recompute and redraw the window shadow and resize the metal texture will add to CPU load if you don't have QE.
7. I am not sure about this, really, but to ensure smooth redrawing without flicker you have to sync with vertical screen refresh frequency. If so, there may be additional delays to smooth the process.
I am not trying to say that window resizing must be slow. I was only trying to explain what happens behind the scenes. Remember that you cannot say the window is resized until it is fully redrawn, that is, all the steps are completed. This is an issue with Mac OS X structure. If Apple engineers manage to make it faster than in Windows on similar hardware, you will owe them a standing ovation.
1) When mouse button is pressed on resize widget, capture graphical state of window.
2) Move the "real" window off screen, into OS X's equivalent of a G-World.
3) As the window is being resized actively by the user, only size the graphical copy of the window.
4) As soon as the user pauses a couple of seconds with the button held, or lifts his or her finger from the button, then and only then should the real calculations be done to resize the window. The computer isn't being forced to calculate a ton of things every second of the drag but rather the ending position of the user initiated operation.
5) The graphical representation is replaced by the newly resized window.
I'm not a programmer, but I don't see why something like this couldn't be accomplished. The user doesn't need the window's contents constantly updated during the drag. Why not implement this "near-live" resizing instead?
This is an issue with Mac OS X structure. If Apple engineers manage to make it faster than in Windows on similar hardware, you will owe them a standing ovation.
Yes, you will, because you hit the nail on the head:
All this is drawn into the window's backing store. AFAIK, none of these can be done in a graphic accelerator.
Windows uses the 2D acceleration hardware for pretty much everything. Very speedy.
Quartz cannot use 2D hardware, period. The hardware doesn't support the things Quartz is trying to do.
Now, with Longhorn (2005? 2006?) M$ will be doing the same sorts of things as Quartz, it seems, and may be able to convince graphics cards makers to design for such effects, in which case we're good to go.
Originally posted by costique
1. My iTunes window has 4 list views (in the browser mode), the top view with the timer/frequency-amplitude graph. It has texture, 3 standard semaphore widgets and 1 standard resize widget. It has a translucent shadow.
2. Each of the list views is NSTableView. NSTableViews work with data sources, that is, there are several methods you define which get called for every NSCell in the view. NSCell is the intersection of a column and a row in an NSTableView. The song list in my config has 6 columns and 15 rows, plus the header. It amounts to approximately > 100 NSCells.
3. Every time you resize the window by 1 pixel, you get at least 3 application-wide notifications sent one after another. They are slow. Much slower than just calling a function in C.
4. For every live resize cycle the graphic subsystem draws > 100 NSCells, each of which contains anti-aliased text, which may generally reflow. The text has to be laid out and anti-aliased again.
5. The top view changes its position and has to be drawn again. So is the window title.
All this is drawn into the window's backing store. AFAIK, none of these can be done in a graphic accelerator. The CPU is busy laying out Unicode glyphs in a sophisticated manner and smoothing their shape, drawing NSCells' interior, calculating their relative sizes, etc.
6. Compositing all this stuff is reasonably fast if you have Quartz Extreme. To recompute and redraw the window shadow and resize the metal texture will add to CPU load if you don't have QE.
7. I am not sure about this, really, but to ensure smooth redrawing without flicker you have to sync with vertical screen refresh frequency. If so, there may be additional delays to smooth the process.
I am not trying to say that window resizing must be slow. I was only trying to explain what happens behind the scenes. Remember that you cannot say the window is resized until it is fully redrawn, that is, all the steps are completed. This is an issue with Mac OS X structure. If Apple engineers manage to make it faster than in Windows on similar hardware, you will owe them a standing ovation.
Yes, you probably explained what happens but most of it SHOULDN'T HAPPEN. Here are some answers to your points:
2) The most important point. As I've already pointed out, none of the NSTableView's have to be rendered again since a) the data source does not change and b) the size of the rendered object doesn't change (it's just clipped differently = zero processing power if done correctly).
3) Personally, I don't think that this is really the problem. Even if it's quite a bit slower than calling a function in C, it still can't explain the 1-3 frames per second that I get on my computer (itunes). And if it's really that slow, either use a different language to program the Panther Finder or implement the whole resizing thing differently as Big Mac has suggested and give the user the option to use either method.
4) Completely unnecessary, see 2). However, I think that this is the main issue as I've already stated. This whole table stuff has to be rewritten to support cached drawing. And even if the table has to be rendered again, why do you think that the table text needs to be antialiased again? The background never changes, so the rendered text regions can be treated as pure graphics, they only need to be clipped or copied but never need to be drawn from unicode during the whole resizing process.
5) That's what I was talking about earlier, and it's about the only justifiable reason. Lighting effects have to be applied to the brushed metal, also text has to be copied on top of it and needs to be antialiasied. However, I should be able to turn off the lighting during window resizing.
6) I have QE and the drop shadow is certainly no problem as window dragging is fast enough. Otherwise, just let the user disable drop shadows during window resizing. Everybody knows by now how beautiful OS X looks, but we should be able to turn off the annoying stuff.
7) Since everything is double buffered, this is already the case.
Big Mac hit the nail on the head.
It's either A or B.
I do NOT care about excuses and I really don't care about live resizing or even if the window turns into an outline or moves the whole thing when I drag it. Honestly I don't know why they didn't just keep it the way OS 9 did it. Until it's fast enough it should've stayed that way. I guess they just wanted to be cool like Windows. But if OS X can't do it realtime it should go. Who wants to hear excuses about a G5 that can't resize a static window like iTunes? It just makes it look bad to a potential switcher. The speed of the GUI in OS X many times betrays OS X's true speed. The GUI speed is how fast OS X "feels" though, and is important in getting work done. It needs to get faster or else changes need to be made, like canning live resizing.
Oh, wait...
Originally posted by Aquatic
The speed of the GUI in OS X many times betrays OS X's true speed.
Oh bollocks.
OS X is *very* fast.
The 2D drawing of the GUI elements is not hardware accelerated, as it is in most other OSs, because it *can't* be given the limitations of the current hardware offerings.
That's it.
It may not *feel* fast to you in that one instance, but to generalize like that is just so wrong on so many levels.
What I said was that saying that unaccelerated complex 2D drawing, in real-time, with a dynamically changing bounding box, is ANY indication of the 'true speed' of the *OS* is just asinine.
You're welcome to your opinion regarding the resize speed, but that's just a blatant fallacy.
But maybe not. *shrug*