[eddiecatflap]

..i thought QE was handling the re-draw..?

..even on my imac - the gef4 is a pretty powerful card and yet it's just as slow as my ibook's rage128.. why?

..can't we return to the outline view of 9 ?

PS

..the open / save dailogs suck too. ( the resize columns thing seems to have gone and i can't see half the item's names )

[juanvaldes]

because it resized every element in the window at the same time.

[WJMoore]

Window resizing is bad because of the window shadow (this is made very evident when you make an application that turns the window shadows off) and also as juanvaldes mentioned because of the live resizing.

Wesley

[shortcipher]

Originally posted by eddiecatflap:
..i thought QE was handling the re-draw..?

..even on my imac - the gef4 is a pretty powerful card and yet it's just as slow as my ibook's rage128.. why?

..can't we return to the outline view of 9 ?

I thought we'd resolved this one months ago! but anyway, yes QE is handling the redraw, but thats all, it doesnt handle the calculation for what the window *content* should look like, thats up to the program in question and the CPU. Once the window contents is rendered QE takes over and shunts it to the video card, where it adds the shadows etc.

So your mileage will vary with different programs, web browsers will be very slow, but other apps may be faster.

PS Some apps do use the outline resizing of OS9, carbon ones that is.

PPS QE has more effect when doing things like compositing a transparent window over a DVD for example.

[OwlBoy]

Resize something in preview, its nice and smooth. And the finder is much improved.

Browsers are slow because of how much is being re-rendered and that the browsers are not as optimized for quick rendering as say IE on windows.

And and for QE: resize a new terminal window its smooth, and if you have it translucent thats being kept smooth by QE.

-Owl

[ARENA]

Well, it was not bad in my Pismo with a GB of RAM and it's perfect in my new Ghz Ti.

[CheesePuff]

Yeah, just fine with any window on my 1 GHz TiBook. Then again most people shouldn't have to spend $3,000 to see a window get resizes smoothly.

[skyman]

The only app that I would consider slow to resize is Entourage. Even on my 1GHz Ti (500 MEG of RAM) it is slow to resize.

No complaints with any other applications.

[Colonel Panic]

urm, iPhoto? iMovie?

[CheesePuff]

Originally posted by Colonel Panic:
urm, iPhoto? iMovie?

fine here

[Toyin]

Originally posted by CheesePuff:
fine here

You mean to tell me that iPhoto and iMovie will resize the windows instantly on your 1ghz tibook? Good resizing means no matter how fast you move the mouse the edge of the window is right with your mouse arrow with no lag.
I've played with Dual 1ghz machines in the Applestore that didn't come close to good resizing with these apps.

[Millennium]

Dtop shadows have nothing to do with it.

Here's the deal. Quartz does not know how to draw only parts of a view; it has to draw the entire view at once. For things like simple, static images, this is not really a problem. But for things like browsers and Finder windows, where a lot of recalculation is in order, it becomes a real chore. QE only handles compositing (the video card also handles pushing it out to the screen but that's not a QE thing), so the CPU has to do all of this recalculation. That kills the performance.

Quartz is a vector-based system, so this does make a little sense. In order to draw part of the screen it needs to know about the whole screen. However, it also ties window-resize performance to view-draw performance.

There are several things programmers can do to mitigate this problem. The easiest one is to simply use OS9-style outline resizing, but currently only Carbon apps can do this. Another way is to really clamp down on your redraw methods when resizing; optimize the hell out of the methods when you can, and if possible use lower-quality but faster algorithms for resize tasks. However, optimization can only take you so far, and sometimes lower-quality algorithms aren't available (as with page reflow for Web browsers). The third option is to not use live-resize at all; "freeze" the window view while you resize, and only reflow when you're done. But no one seems to like this option very much.

Personally, I'd be happy with outline resizing; I don't see live-resize as anything but useless fluff except in certain very specific cases (such as performance monitors).

[pat++]

There is no good reason/excuse for the slow resizing. Hopefully 10.3 will eventually fix this issue which has been around for too long. Otherwise, I would really be happy to have an option in System Preferences to disable realtime resizing.

[Millennium]

Originally posted by pat++:
There is no good reason/excuse for the slow resizing. Hopefully 10.3 will eventually fix this issue which has been around for too long.

Um, I think I've already explained it.

Live resizing involves redrawing the window. This is true on all operating systems, including Windows. Apple has done most of what it can, at least as far as the core OS is concerned. The rest has to be dealt with in apps; if your redraw method is slow, then no amount of optimization by the OS will make it fast.

Otherwise, I would really be happy to have an option in System Preferences to disable realtime resizing.

This would be a Good Thing, yes.

[Developer]

Originally posted by Millennium:
The third option is to not use live-resize at all; "freeze" the window view while you resize, and only reflow when you're done. But no one seems to like this option very much.

TextEdit does that.

[Toyin]

Originally posted by Millennium:
Um, I think I've already explained it.

Live resizing involves redrawing the window. This is true on all operating systems, including Windows. Apple has done most of what it can, at least as far as the core OS is concerned. The rest has to be dealt with in apps; if your redraw method is slow, then no amount of optimization by the OS will make it fast.

This would be a Good Thing, yes.

Are you sure about this? Windows machines that are 3-4years old will resize windows to any apps (including video) very well. It seems that in windows the primary concern is keeping the mouse arrow attached to the corner of the window at the expense of content redraws. The contents will flash more slowly for complicated windows and quicker with simpler windows. I don't know jack about OSX core graphics, but I think the priority should be on keeping the mouse and the window corner together. In the worst case scenario, the contents will only redraw the contents once (almost like outline resizing). The faster the hardware the more redraws you'd get. Even on the fastest Apple hardware an app like Preview can't keep up with the mouse being moved around as fast as possible. There's still a slight lag. On a 200mhz PII with a crap video card you get no lag, but crappy redraws.

[Toyin]

Originally posted by Developer:
TextEdit does that.

My textedit reflows text live.

[Developer]

Originally posted by Toyin:
My textedit reflows text live.

Mine does too, as long as it's feasible to do so.
Enter a lot of text and scroll to the bottom of the document. Then it will wait with recalculating line breaks until you release the mouse button.

This is the most clever implementation of live window resizing. Unfortunately I haven't seen it yet in any other application (probably works so good that nobody even noticed it).

[ZackS]

Another fantastic example is stickies. Just thinking of the simplicity of the sticky window, running [self:display] constantly durring resize works really well. Other apps do this but really shouldn't. I agree that the way textedit breaks from this is perfect (almost).

[CheesePuff]

Originally posted by Developer:
Mine does too, as long as it's feasible to do so.
Enter a lot of text and scroll to the bottom of the document. Then it will wait with recalculating line breaks until you release the mouse button.

This is the most clever implementation of live window resizing. Unfortunately I haven't seen it yet in any other application (probably works so good that nobody even noticed it).

Plus if you have the ruler, etc. on it will wait until you stop moving the mouse.

[tooki]

It's just irritating that many PCs running Windows 95 back in 1996 could do live resizing smooth as silk, and Macs STILL can't do it.

tooki

[DeathMan]

I know. When the 970s come out and macs are fast again, they'll still say, well window resizing sucks on macs.

when will we be the best at everything? EVERYTHING!!!!111

[King Bob On The Cob]

Originally posted by tooki:
It's just irritating that many PCs running Windows 95 back in 1996 could do live resizing smooth as silk, and Macs STILL can't do it.

tooki

It doesn't help that Apple has Quartz rendering whatever you display twice. Just so you won't see the white flash when you resize. (Text would render faster if they didn't double buffer it.)

[GaelDesign]

Originally posted by tooki:
It's just irritating that many PCs running Windows 95 back in 1996 could do live resizing smooth as silk, and Macs STILL can't do it.

tooki

But Windows flickers like crazy all over the place -- even on a 2.5GHz P4 with a fast ATI Radeon (I've seen it).

I'll take "slow" redraws over flickering anyday.

Jared

[Agent69]

I think outline resizing would be a nice control panel option. I suggested that to Apple once but they chose not to include it.

[MindFad]

Originally posted by tooki:
It's just irritating that many PCs running Windows 95 back in 1996 could do live resizing smooth as silk, and Macs STILL can't do it.

tooki

Quartz is, of course, completely different and much more complex than the drawing engine in Win 95, I'm sure.

[funkboy]

It's choosing whether or not you like the flashing that Windows live-resizing has. It's like resizing OS X windows on top of OS 9 windows - there's flashing and white part of windows visible.

I personally prefer OS X's more stable feel altogether.

[idjeff]

Originally posted by Agent69:
I think outline resizing would be a nice control panel option. I suggested that to Apple once but they chose not to include it.

Those bastards!

[pat++]

Originally posted by Millennium:
Um, I think I've already explained it.

Live resizing involves redrawing the window. This is true on all operating systems, including Windows. Apple has done most of what it can, at least as far as the core OS is concerned. The rest has to be dealt with in apps; if your redraw method is slow, then no amount of optimization by the OS will make it fast.

You mean that all apps out there on the Mac are poorly written and that on Windows, you only have greatly written apps which have been optimized to draw the content of their windows? come-on....

[SMacTech]

Originally posted by GaelDesign:
But Windows flickers like crazy all over the place -- even on a 2.5GHz P4 with a fast ATI Radeon (I've seen it).

I'll take "slow" redraws over flickering anyday.

Jared

I will second that. The way that Windows redraws in Explorer can cause epileptic fits when using it.
When using OS X, all windows are double-buffered and it doesn't require an app to refresh the window's content when a window is brought to the front or another window is dragged over top of an underlying window.
The result is a smooth non-flickering UI and better performance overall. In OS 9, each time a window was moved over another, the underlying window needed to be redrawn by the app, using more cpu% in the process. This does not occur in OS X, as the app never receives a window refresh event, instead the Window Manager has a copy of the window stored in RAM, ready to recomposite to the display.

[dfiler]

Wow. Where to begin. This topic has been covered numerous times. Not to say that it shouldn't be brought up again for the curious... Rather, that some of the more knowledgeable people may have tired of answering the same question.

Window resize speed has almost nothing to do with quartz being double buffered or the text being anit-aliased. It is almost entirely CPU bound on current systems. Laying out and compositing a tree of translucent views can be quite CPU intensive on non-QE machines. Even on QE enabled computers, layout and dirty region calculations are what really take so much processing power.

Notice how most cocoa apps suffer from poor redraw speed? This has to do with NSView being such a heavy weight class. It is easy for programs to have hundreds of NSViews (and sub-classed views and controls). Each of these must be resized, position, and sometimes redrawn before being composited back into an image for display.

Also, there are a few glaring holes in OS X's cocoa implementation. Most notable is its incomplete dirty region management. The algorithms, used to figure out which parts of which views need updating, is currently an non-optimized hack. The cocoa API has the right hooks, yet currently, they are simply ignored.

I would be willing to bet that Safari is using its own custom classes rather than sub-classes of NSView or NSControl. NSViews just contain too much functionality to run efficiently under the current region update schema. I seem to remember Omni developers considering this route and commenting on the heavyweight nature of NSView.

Even with these shortcomings, I'm still a fan of Cocoa. It is well architected and future optimizations will be facilitated by its mature programming interfaces. Optimization of dirty region management wasn't such of an issue prior to glitz of quartz. However, Cocoa was well designed and will allow for more optimization over time.

Window resize will always be slower on systems which actively update window contents or provide low level support for translucency. Apple realized both of these drawbacks when designing quartz. Unfortunately, the G4 has stagnated for a few years now. Its likely that quartz was designed with the assumption that Moore's law would hold. Since it hasn't held true for G4s, Apple has been desperately trying to compensate with software optimization. It will be ironic if this optimization makes it to our desks at the same time as the 970...

Does anyone know if Apple is close to fixing dirty region management in Cocoa?