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)
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.
Comment 3•23 years ago
|
||
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
Comment 4•23 years ago
|
||
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.
| Assignee | ||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → Chimera0.9
Comment 6•23 years ago
|
||
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.
Comment 8•23 years ago
|
||
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
Updated•23 years ago
|
Summary: [RFE] Live window resize is slow; Implement outline window resizing → Live window resize is slow; Implement outline window resizing
Comment 9•23 years ago
|
||
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.
Comment 10•23 years ago
|
||
> 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.
Comment 11•23 years ago
|
||
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.
Comment 12•23 years ago
|
||
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.
Comment 13•23 years ago
|
||
Agree with WONTFIX ... this is something for apple to fix in the OS, not
individually at the App level.
Comment 14•23 years ago
|
||
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
Comment 15•23 years ago
|
||
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.
Comment 16•23 years ago
|
||
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.
Comment 17•23 years ago
|
||
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?!
Comment 18•23 years ago
|
||
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?
Comment 19•23 years ago
|
||
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.
Comment 20•23 years ago
|
||
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.
| Assignee | ||
Comment 21•23 years ago
|
||
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.
Description
•