Closed
Bug 13131
Opened 25 years ago
Closed 25 years ago
repainting everything between progressmeter and throbber
Categories
(Core Graveyard :: GFX, defect, P3)
Core Graveyard
GFX
Tracking
(Not tracked)
VERIFIED
FIXED
M12
People
(Reporter: dbaron, Assigned: pavlov)
References
Details
(Whiteboard: [PDT+][Perf]Rendering Performance; 11/26 12/6: Request verification by reporter)
Attachments
(3 files)
I reported this on mozilla-layout a few days ago, and I'm now turning it into a bug. DESCRIPTION: While a page is loading, updates to the throbber and to the progressmeter cause the entire area between them to repaint. I'm not sure if this problem is a general problem with the compositor or something specific to animated GIFs (like the throbber). This shows up when one does things like hover over links (or click on a new link), and the part to the left of the left edge of the progress meter updates more slowly. I built with --disable-double-buffer so I could see repaints using a checkout from Sat 1999-08-28 at 12:15 PDT, and it is clear that the repaints are covering the entire rectangle from the bottom left of the progress meter to the upper right of the throbber. I suspect what is happening is that whatever decides what area to repaint is taking the union of the two rectangles in this (somewhat strange for this case) way: ---------------------------***** | * * | ***** | | | | ******** | ********------------------------ This may not be a bad idea for web pages in general, but it isn't too great for the chrome. I made two test pages (which I will attach) that contained (1) two active throbbers and (2) two active progress meters. The painting problems showed up in the one with throbbers but not with the one with progress meters. (There's no way to see that without disable-double-buffer.) So I don't think this is really a problem with the progress meter (although I've heard it blamed a number of times). There are a number of questions here in my mind: * when the document has changed, why hasn't the necessary repaint region for the document gotten into the list of things to be repainted * would it be more efficient to turn paint requests for two distant rectangles into two separate requests? In this case, I think the answer is yes. But would it in general? The problem with this bug is both that: * the older/newer line down the document is ugly * repainting the document so much is a performance problem and sucks up a lot of CPU (near 100%). I'm 90% sure I've seen this on Windows, so I'm marking All/All. Please correct me if I'm wrong. STEPS TO REPRODUCE: * Build with --disable-double-buffer * Start apprunner * Load URL http://www.fas.harvard.edu/~dbaron/ , because it has a dark background and the links change on :hover ACTUAL RESULTS: * whole huge rectangle flashes while the page is loading (or, without disable-double-buffer, you see weird things at the edge of that rectangle) EXPECTED RESULTS: * only the area of the progress meter and the throbber should repaint DOES NOT WORK CORRECTLY ON: * Linux, apprunner, 1999-08-28, 12:15 PDT build (attachments tested using viewer)
Reporter | ||
Comment 1•25 years ago
|
||
Reporter | ||
Comment 2•25 years ago
|
||
Reporter | ||
Comment 3•25 years ago
|
||
Reporter | ||
Comment 4•25 years ago
|
||
I take back my original comments about this not happening with progress meters alone. It does. Somehow I didn't see it on Tuesday. (Perhaps my system was a little faster...)
Updated•25 years ago
|
Status: NEW → ASSIGNED
Whiteboard: Rendering Performance
Target Milestone: M14
Comment 5•25 years ago
|
||
Confirmed. This is by design. Clearly sparse content is not rendered very efficiently. This is probably a case where rendering each view separately would be better, or perhaps rendering directly to screen would be better, since each view simply blits. I think we should provide a way to hint that a view shouldn't be double buffered, and so it should not be composited in the usual way. this would optimise redraws of the chrome, as long as they consist of simple blits.
Comment 7•25 years ago
|
||
Adding chofmann so he can add this to his must-fix-for-beta dependency tracking bug. /be
Whiteboard: [Perf]Rendering Performance → [PDT+][Perf]Rendering Performance
Comment 10•25 years ago
|
||
I'd like to add a note that since (presumably due to another bug) these over-zealous paints are able to completely starve the network code of the time to empty the network buffers and hence render the browser essentially unusable on Linux, this is a more critical bug than I first thought. I noticed this on the paint team to-do list, however: "Maintain a invalidated rect list rather than growing a single invalid rect. Update the invalidate rect list if a view is scrolled after the invalidated rect has been specified." That work is slated to be done by beard for 1999/11/19
Comment 11•25 years ago
|
||
Patrick is in the midst of moving into his new home, but promises an estimate tonight.
Whiteboard: [PDT+][Perf]Rendering Performance → [PDT+][Perf]Rendering Performance; 11/26
Comment 12•25 years ago
|
||
This is waiting on getting nsIWidget::InvalidateRegion() implemented on linux. I can probably write the code, it looks easy. I need somebody to help verify my changes. I'll probably work with Chris Saari on this, since he has a linux box I can verify with. This could be ready tomorrow.
Comment 13•25 years ago
|
||
How is this looking? I think this is the source of our msg display performance for linux (Bug #17062). If I turn off the throbber and progress meter, the number of repaints goes down dramatically and the message display speeds gets much better to the point of being useable again). I'm willing to help try out any patches on linux to help verify this.
Comment 14•25 years ago
|
||
Latest porkjokey update on invalidated-rect-list work (presumably covering this issue) being done by Patrick Beard says this: "Completed on WIN32 and Mac. Problem on Linux. (Linux doesn't run with changes in place, gets XServer error.) Can't check in." Is seeking help from Pavlov. ETA moved back to 12/03/99.
Assignee | ||
Updated•25 years ago
|
Assignee: beard → pavlov
Status: ASSIGNED → NEW
Assignee | ||
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 15•25 years ago
|
||
beard has checked in needed changes in view manager and I have checked in linux fixes. This also fixes 17062.
Updated•25 years ago
|
Target Milestone: M14 → M12
Updated•25 years ago
|
Whiteboard: [PDT+][Perf]Rendering Performance; 11/26 → [PDT+][Perf]Rendering Performance; 11/26 12/6: Request verification by reporter
Comment 16•25 years ago
|
||
David: Can you help me in verifying this bug is fixed. I'm not sure what I need to do so. I need to get this verified today if possible. Thanks for your help.
Reporter | ||
Comment 17•25 years ago
|
||
My most recent debug build was 2 and a half hours before pavlov and beard checked in the changes (14:27 / 14:33 on 1999-11-30). This means I would have to pull and build to verify this. That's not going to happen tonight... If you have access to a debug build, you can probably verify it using paint flashing. (Except I noticed last week (I think) that paint flashing isn't flashing for all paints anymore, so I probably should do a build with --disable-double-buffer, if that still works...)
Comment 18•25 years ago
|
||
Stuart, I don't have ability to build a linux with disable-double-buffer version. Could you please mark this as verified with the latest build ?
Assignee | ||
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Updated•15 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•