[Alex Duffield]

I havent heared one single complaint about the way iTunes resizes its windows... outlines... just like in OS9!

And that suites me just fine!

I dont need nor want live resizing of finder windows until it is as fast as outlined resizing.

Is there a hack to make finder windows not live resize??

[michaelb]

On the other hand, has anyone tried resizing windows full of text in Stickies?

Probably not, as Stickies is such a girl's program. (Sorry to any girls here for my total lack of political correctness!)

But try it. Fill a Stickies note with text and drag the resize widget.

Phenomenally fast, isn't it?!

Dynamic resizing with high frame rates, at least on my G4 450. Wouldn't it be nice if the Finder was like this...

[Ohyeahz]

Same for the Script Editor. Blazing fast.

[Developer]

The system is fast enough to do live resizing. There is absolutely no need to fall back in outline resizing!

To see what the real problem is make the following experiment:

Open TextEdit and enter some text at large size (and maybe a font that supports ligatures like Zapfino). Now resize the window. You'll notice that TextEdit recalculates line breaks in real time. Line break calculations are expensive, but with not much of text it is fast engough.

Now copy your text and paste it in several dozens of time. Make sure you scroll up to the top of the document and resize the window. Again TextEdit recalculates the line breaks in real time. There is a lot of text, but only the few top lines are visible and need to be rebroken, so TextEdit is fast enough to do it.

Now scroll down to the buttom of the document and resize the window. You'll notice that this time TextEdit does not recalculate line breaks in real time. It would have to calculates line breaks from top to bottom of the document, isn't fast enough to do so, and therefore doesn't even try it. Line breaks are calculated only after the mouse button is released. The window is still live resized (no need to fall back to oultline resizing), but the content is not.

TextEdit does it all right! Compare this to - for example - OmniWeb on web pages where line calculations have to be done when resizing. No matter how complex the page is, OmniWeb always tries to do it in real time and necessarily fails at some point. On pages that do not require line page recalculations (for example www.apple.com) resizing is kind of OK.

Now take the Finder as an other example. Resizing a window in icon or browser view is fast(er), but list view is horribly slow. Add some more information to the list and it's even slower. The Finder obviously doesn't cache these information and retrieves them every time it has to redraw the window.

Conclusion:

a)
Apple can speed up window resizing by further optimizing Quartz, but not much.

b)
Some apps must optimize the way they draw their window content. For example by caching information (Finder list view) or by drawing into an offscreen buffer the size of the document and only blitting that buffer into the window buffer. Classic Macintosh apps never had to be fast here, so their Carbon counterparts are not yet optimized for this.

c)
Applications should give up trying to resize their content in real time no matter how complex it is. At some point they should give up, only resize the window (and things that are fast to draw like tool and status bars) and redraw/resize the content only after the mouse button is release.
Framwork vendors could help to implement this (so Apple could probably help Cocoa developers to make that the default behavior), but most of the work must be done by the application developers.


And by the way: the iTunes window is not too complex. It should live resize fine.


Developer

[Todd Madson]

Believe it or not, the carbonized napster client has the fastest live-resizing windows I've tried. Amazing.

[clebin]

I resent you calling Stickies a girls' program!

As a bloke, I think it's great! Lucky it's so against Windows' Maximise/Minimise method of working or Microsoft would've ripped it off by now.

Chris

[Angus_D]

Originally posted by Developer:
And by the way: the iTunes window is not too complex. It should live resize fine.

But it does appear to be attempting to draw the Aqua controls manually. Looks to me like Apple used some haquery to make the controls look like Aqua on 9.x, and hasn't bothered/had the time/whatever to change it to use proper calls for the listboxes and so on - notice that when you switch to Graphite, the controls don't update.

[Scrod]

Not true. iTunes acquires the graphite appearance:

[Skywalkers new Hand]

Originally posted by Alex Duffield:
I havent heared one single complaint about the way iTunes resizes its windows... outlines... just like in OS9!

Actually, I complained about it here a couple weeks ago. I like live resizing, when it works. http://forums.macnn.com/cgi-bin/Forum3/HTML/005164.html
-------------------

[foobars]

Originally posted by Scrod:
Not true. iTunes acquires the graphite appearance:

I think he was referring to the control buttons, scrollbars, checkboxes and list bars, which are graphics, not true aqua elements. Notice these DON'T change with the Aqua appearance. All that blue in your screenshot would be grey if iTunes was truly OSX appearance compliant. They are faked, thus the lack of live resizing.

Don't ask me why Apple felt they had to fake their own interface- you would think it would be easier to just throw this together in IB...


[This message has been edited by foobars (edited 05-04-2001).]

[robre]

It would be a nice feature to be able to option or control drag a window to resize (using the outline of the window) without live update for those who find it too slow.