Closed Bug 185598 Opened 20 years ago Closed 20 years ago
Don't repaint window contents when resizing a pane with mouse
I'm currently using trunk 2002121408. I'm running MailNews on a moderately fast machine (196MB RAM, Celeron 433), but the video card is quite slow (SiS 620) and repainting a window is a costly operation. Resizing a pane in MailNews is horribly slow, because with each move of the mouse (when dragging a pane's border) the window is repainted. I suggest that repainting of the whole window be replaced with drawing a dim, grey border line instead. The line would indicate where the pane border will be placed afted the user releases mouse button. The whole window should be repainted after the user releases the mouse button so he/she can check whether he/she is satisfied with new layout. On Windows, Mozilla could listen to the "Show window contents when dragging" option of the UI (available on the "Effects" tab of the display settings - right-click on the desktop, go to "Effects" tab.) and do full repaiting if that option is enabled.
Dupe of 185533, or at least related?
*** This bug has been marked as a duplicate of 185533 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
marking as duplicate
Status: RESOLVED → VERIFIED
Sorry, I disagrre that this is a dup. Skip the part about respecting "Show contents while dragging" on Windows - what I mean is, on all OS-es, the default should be to not update window structure in real time - only draw a temporary border while dragging and update after the mouse button has been released. On X remote window, for example, this would reduce traffic between the client (Mozilla) and the X server (e.g. XFree86) considerably. In general, on every system, it would hugely increase performance without any doubt (adding topperf keyword). Bug 185533 is related, but specific to Windows. Please consider reopening this bug.
You need to log in before you can comment on or make changes to this bug.