Closed Bug 160237 Opened 23 years ago Closed 23 years ago

Live window resize is slow; Implement outline window resizing

Categories

(Camino Graveyard :: General, enhancement)

PowerPC
macOS
enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX
Camino0.9

People

(Reporter: joe, Assigned: mikepinkerton)

Details

(Keywords: perf)

Window resizing would be a lot smoother and feel a lot speedier if trace lines were implemented for window resizing and the window waited to redraw until after release of the mouse.
Note that live window resizing may be sped up by Quartz Extreme in OS X 10.2. Joe, are there any OS X applications that presently implement such "trace lines?"
URL: any
Hi Greg! Microsoft Word, Excel, PowerPoint and Macromedia Dreamweaver MX use the trace line thing for window resizing. Quartz Extreme will certainly help the more recent machines, but the older ones will be left behind. I am not experiencing much benefit from Quartz Extreme on my first generation PowerBook G4.
Pinkerton, is window resize bad enough that we want to do this? It is pretty doggy on my TiBook 500, but I don't do it that much either.
Assignee: saari → pinkerton
Summary: Implement trace line for window resizing → [RFE] Speed up Window Resize; Implement trace line for window resizing
Hi Guys. Just thought I'd chime in about this resize problem. First off, resizing a window with many tabs open is painfully slow. The whole window flashes white before redrawing, this is certainly not good. However, I would have to say that "trace lines" is not the way to go either. Trace lines are used ONLY by carbon apps that haven't implemented live window resizing. For a cocoa app to use trace lines would be a very bad thing. Not to mention the fact that I'm not sure if it's even possible. I recommend finding a way to delay page content redraw until after the window has completed it's resizing operation. There is a notification your window delegate can register for that will tell you when the window has completed the resize operation. Using this mechancism would prevent pages from being re-rendered durning the drag-resize operation. This would speed things up and prevent windows from flashing white when resizing. BTW, I'm running on a 500 Mzh TiBook as well.
Apple is claiming improved window resize performance in 10.2 with and without Quartz Extreme (see [http://www.apple.com/macosx/jaguar/quartzextreme.html]). Let's wait and see how much that helps.
Status: NEW → ASSIGNED
Target Milestone: --- → Chimera0.9
Chimera's resize performance seems quite good to me on Jaguar. It's not smooth, but always stays responsive (on this page, 3 tabs open, G4 466Mhz). It might be a good idea to only reflow the content a few times a second instead of with every pixel the user moves the window.
This is indeed better with 10.2. Still seems delayed a bit on my PowerBook G4 500, but at least it's not disruptively slow in this version of Mac OS X.
Window resize is still slow on Jaguar with lots of tabs, I think.
Keywords: perf
Summary: [RFE] Speed up Window Resize; Implement trace line for window resizing → [RFE] Live window resize is slow; Implement outline window resizing
Summary: [RFE] Live window resize is slow; Implement outline window resizing → Live window resize is slow; Implement outline window resizing
Can we get a system where the content of the window isn't reflowed unless the user doesn't move the window for a set period of time; for example content would not be reflowed and therefore resize performance would be excellent, but if you held the window in one place for 1 second we would update the contents. Failing that, we could just wait to reflow the contents until the user let go of the mouse. This should offer the speed of outline resizing while still acting mostly like a cocoa application.
> Can we get a system where the content of the window isn't reflowed > unless the user doesn't move the window for a set period of time The content doesn't need to be redrawn until the user ends the resize operation. If the window starts to redraw itself while the user is still trying to make up their mind about how big or small they want the window to be, the sudden redraw will result in an unexpected slowdown -- potentially causing more annoyance than the current constant redraw setup.
I've just enterred <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=181147">bug #181147</a>, "Window resizing is one step behind mouse pointer -- doesn't repaint when mouse pointer stops moving," which is related to this.
Live window resizing is part of Aqua. If it is too slow in Chimera, it's probably too slow in other apps, too. However, it should be disabled at the OS level by some third-party utility, not the app level. Recommend WONTFIX.
Agree with WONTFIX ... this is something for apple to fix in the OS, not individually at the App level.
I think what people are asking for is something similar to what Apple does in TextEdit with a large document. If you're in the middle of the document it doesn't re-flow the text but instead either clips the current contents of the window (if you make the window smaller) or adds white space if you make it larger. When you 'let go' of the window resize widget then it re-flows the text to fit the page. I think this is the applicable info from Apple: http://developer.apple.com/techpubs/macosx/Cocoa/Reference/ApplicationKit/ObjC_classic/Classes/NSView.html#//apple_ref/occ/instm/NSView/inLiveResize http://developer.apple.com/techpubs/macosx/Cocoa/Reference/ApplicationKit/ObjC_classic/Classes/NSView.html#//apple_ref/occ/instm/NSView/viewWillStartLiveResize http://developer.apple.com/techpubs/macosx/Cocoa/Reference/ApplicationKit/ObjC_classic/Classes/NSView.html#//apple_ref/occ/instm/NSView/viewDidEndLiveResize
Actually i dont know how wuch live resizing is part of aqua... quicktime, itunes, opera and some microsoft products use outline resizin which is faster.
Outline resizing isn't any faster than live resizing if you don't reflow the window contents; Microsoft apps that use outline resizing are just a result of lazy programming, and iTunes uses live window resizing. Even when we are reflowing the window content while the user resizes the window, our response time is pretty good; Chimera resizes much smoother than apps like iTunes and iCal.
I don't find Chimera's window resizing particularly slower than that of most other OS X apps that use live resizing. Maybe Apple will be able to make it work faster in subsequent udpates. Re: Comment #16 From Steve Smart 2002-11-23 11:42 > iTunes uses live window resizing. Not in my copy?!
iTunes 3.0.1 (66) in 10.2.2 has live resizing. I find chimera's resize speed to be OK but not fantastic. Yes, there's ways to tweak things in Cocoa to probably make it seem faster like pointed out in Comment #14. Differences between apps may reflect the use of Carbon?
From Apple Human Interface Guidelines (Page 81): "In Mac OS X, the actual window contents are displayed at all times, rather than only the window outline displayed in Mac OS 9." Recommend status "WONTFIX." Quicktime, iTunes, Opera, and the MS Office products you are referring to (MS Word, Excel, etc.) are all carbon applications -- direct ports from OS 9). I expect that they'll change this some time in the future. Doing a "quick-and-dirty" redraw with white space would be ok, though.
chimera's resizing speed is similar to that of apple's mail app. as such, WONTFIX makes a lot of sense, as i assume apple is working hard to improve window resize performance.
i have no problem with this on my 500 g3 laptop. wontfix.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.