I forget the difference between draw and paint but if you grab the resize widget in the bottom right corner of a browser window and drag it around even a little bit one can see the window struggling to redraw itself. This deficiency was immediately and strikingly obvious to me at first glance on a 500Mhz G4 Mac with a 20020816 1.0 branch build. To repro: Load any page. Repeatedly resize the window by dragging the mouse around while holding the resizewidget. Observe. Expected Results: The window should jump(slide?) from size to size smoothly with no visual artifacts. Actual results: Artifacts of where the chrome was were left in the content area as the window resized. Build and platform info: Reproduced on Mac OS10.2 on a 500Mhz G4 with 256MB memory and nothing else of significance running. 20020816 branch build NOT a problem on Mac OS10.1.5 on a 533Mhz G4 with 256MB memory and nothing else of significance running. 2002081613 branch build. Just in case you might believe the 33Mhz makes a difference I tried with a 450Mhz G3, with 128MB memory and several OS utilities open and saw no ill effects.

It's often worse than this image suggests but this picture is the best(worst) I could capture. Notice the CPU monitor readings and that nothing other than that is running.

i'm guessing one way they sped up window resize is to not always notify the application that its size has changed. not quite sure what to do about this.

-> dagley i'm pretty sure se already filed this bug

Does this only happen on certain hardware (maybe Quartz Extreme-related)?

yeah, i had originally filed this in bugscape: http://bugscape.mcom.com/show_bug.cgi?id=19008 this would also be an issue in mozilla.

lowering severity as AFAIK we do properly repaint the entire winow once the drag stops

Anybody object if I mark this WONTFIX? While our redraw is somewhat worse than other apps all of the apps I tested seem to have some sort of issue resizing under 10.2.2. As sfraser mentions it's related to Quartz Extreme.

interesting, hadn't noticed this problem with other apps on jaguar. again, it might be coz they weren't as obvious...

I think it's also different between Cocoa and Carbon apps FWIW

Since I don't report into Internet Technologies anymore this bug needs a new owner -> saari I recommend this be marked WONTFIX

can anyone reproduce this in Chimera or is this NS/Mozilla specific?

this is specific the nscp/mozilla. it's more obvious on slower machines (eg, G3 450mhz, 384MB ram --my old box), but less so on faster ones (G4 500mhz, 512MB ram).

I am _begging_ to get this fixed for the 1.3 version. If it is not fixed my company will have to continue using Netscape 4.76 on Red Hat 6.x for mail. Can you believe it? We are in the midst of migrating to Red Hat 8 and have really hit a wall on this. I believe that this bug may be the same or is very closely related to: Bug 84920 Bug 89919 ?? maybe Bug 104176 Bug 103241 Bug 136230 Bug 163264 I am reporting the same message to these other bug nubmers. This bug is extremely serious to those users that it affects and makes Mozilla -- ESPECIALLY THE MAIL which does constant opening and closing of windows -- unusuable in a business/production environment. Several reporters have stated this, but so far -- after more than 18 months -- to no effect. I believe that this bug has not received the proper attention because: 1) It was spread over many reports that used varying terminology. 2) It was assigned to various people, one of whom appears to have been oblivious about it before he become employed elsewhere. Nobody seems to have realized that all these reports are about the same thing. 3) ***** The bug is less noticable on faster or dedicated systems that developers and engineers are more likely to use. However, for a business user working over a busy network, connecting to a busy server, it is a PRODUCTIVITY KILLER. The distillation of all the reports is: PROBLEM: A) Any screen redrawing resulting from window opening, closing, moving, minimizing/maximizing, or resizing is EXTREMELY SLOW, particularly when multiple Mozilla windows are open. Redrawing is also very slow when focus is changed from one mail folder to another or when the user right clicks on a mail folder to get a context menu. For example, when I move THIS browser window, I momentarily see FIVE (5) duplicates of this window and I can count four seconds before all the screen redrawing is done. Resizing is even slower -- it take about an 8-count before the screen is redrawn. Closing this window also takes about an 8-count before the screen is fully redrawn. Minimizing this window is quite bizzare; there are about fifteen (15) momentary black-outlined rectangles getting smaller and smaller as it minimizes; a 5-count before all redrawing is complete. B) If you are working only in one screen typing like I am now, this is not a big deal. However, _MAIL_ users are constantly opening message windows, changing focus between IMAP folders, etc., etc. As I have spent a couple days test using the mail, I have made many mistakes because I thought all the redrawing was done when it was not. As a result, messages have been dragged to the wrong folders, folders have been expanded or unexpanded when I was trying to do the opposite, etc. (I have tons of experience using NS 4.76 doing the exact same work and have never had any of these kinds of problems.) This is a PRODUCTIVITY KILLER for mail users. C) Reporters have reported this on: Linux X11 Linux (ver not stated) on a PC Windows 95 PC Windows NT4 PC Windows NT 5.1 Windows 2000 OS X on iMac & G4 (but maybe only 10.2 or higher??) Sun OS (version ?) Solaris 2.8 D) All reporters seem to be reporting on reasonably (to very) fast machines with decent to excellent amounts of RAM. E) Several reporters have clearly stated that it is "virtually unusable" or otherwise not useable in a business environment. I must agree! MY EXPERIENCE: 1) This Mozilla is running on a Red Hat 8 server to which we are migrating. Our migration is essentially stalled until this issue is addressed. I cannot believe that I am going to have to keep running a Red Hat 6.x server to provide Netscape 4.76 email to my staff! Red Hat 8.0 with kernel 2.4.18-18.8.0 and all but the latest (i.e. last two weeks) updates via RH up2date. UW IMAP vers 2001a release 15 from Red Hat supplied RPMs (from RH install CD). Mozilla 1.2.1 (Xft build) from Mozilla RPMs Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202 2) When we first saw the problem, we assumed that it was an X problem, so we tested per the below. The workstations are Windows 95 PCs (we hope to be Microsoft free by the end of 2003!) running X windowing software to provide X access to the Linux servers. *** NOTE THAT THIS X WINDOWING (and 10 mb network in general) IS PROBABLY PROVIDING SOME OF THE DELAY THAT MAKES THIS BUG MORE OBVIOUS. (It is sort of like testing an application over a 28.8 kb modem to see what is really going on.) HOWEVER, _ALL_, I REPEAT _ALL_ OF OUR OTHER RH 6.X AND RH 8 APPLICATIONS DO _NOT_ HAVE ANY OF THESE REDRAW SPEED ISSUES, EVEN WHEN THE NETWORK IS UNDER HEAVY LOAD. a) Tested through SCO's PC XVISION 7.32 running on Windows 95 running Mozilla running on our RH 8 server. Mozilla is the only application that shows any redraw speed problems. This is our oldest Xwindowing software. The PCs tested were 300 to 400 MHZ machines with 256 to 512 MB of RAM. b) Tested through CYGWIN XFREE86 4.2 (the latest production release) running on Windows 95 running Mozilla running on our RH 8 server. Mozilla is the only application that shows any redraw speed problems. On this newer Xwindowing software, the redraw problem was perhaps 20% less (20% faster) than on the XVISION. The PC tested with Cygwin (specifically installed for THIS test) is a 400 MHZ machine with 512 MB of RAM. c) Tested directly on our Red Hat 8 server console (i.e. no network, PC, or windowing software to slow things down) running DUAL 1 GB processors with 3 (three) _GB_ of RAM. Redraw is noticable, but would not bother anybody. When moving one Mozilla browswer window around on top of another, I get momentary duplication of the chrome -- about five to six copies of the window. By comparison, similar window movements of other application windows on this machine do NOT show this delay -- for other applications, redraw is instantaneous. However, as I said, it is perfectly usable -- BUT not every staff member (none, in fact) can use the server as a workstation! Please help! Jay

Jay: this bug is specific to Mac OS X. I see you've already added your comments to those other bugs.

Simon: From what I am seeing and reading, I suspect that this (#163264) bug is _not_ specific to OX X / Mac. It is just that the particular intial reporter was using a Mac and nobody put 2 + 2 together. This bug is showing up virtually everywhere. I believe that it may be appropriate to combine/link all these bugs -- and escalate the severity because it seems to be the same problem affecting all systems in the same way. Thanks. -- Jay

No, this is about Mac OS X. It was filed on the performance difference between window resize on OS 10.1, and 10.2. I think your issues really are Linux-related, and are probably related to unix gfx/widget code. It's not generally productive to spam multiple bugs with copies of the same text.

Simon: I have read all of what I think are the related bug reports several times. I must respectfully disagree with your conclusion. More than half the reporters are reporting the a virtually identical set of problems (it is just thas some reports were more complete than others) on various flavors of Mozilla on MS Windows. At least two were on Sun. At least two were on two (or maybe three) different flavors of Mac. I really believe that the various reporters were all talking about the same thing -- it is just that one was taking about the trunk, another a leg, and another the tail; nobody was talking about the elephant. My apologies for "spamming", however, there was no other way to let all related parties know that each may be holding onto only part of the elephant. I will say no more unless spoken to. I really am trying to do the right thing and to not be annoying. -- Jay

This is not MacOSX specific! I can verify seeing this under both Windows 95 and Linux (Red Hat 8.0) using the latest stable releases (1.2.1). See bug 84920 for my report.

Rich, do you see this? (steve, comment 10, appears to be gone)

No new useful information since previous recent comment #19, comments #18 and before were from Jan 2003, resolving incomplete.