Closed Bug 13131 Opened 25 years ago Closed 25 years ago

repainting everything between progressmeter and throbber

Categories

(Core Graveyard :: GFX, defect, P3)

defect

Tracking

(Not tracked)

VERIFIED FIXED

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)
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...)
Status: NEW → ASSIGNED
Whiteboard: Rendering Performance
Target Milestone: M14
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.
Whiteboard: Rendering Performance → [Perf]Rendering Performance
Putting on [Perf] radar.
Adding chofmann so he can add this to his must-fix-for-beta dependency tracking
bug.

/be
Blocks: 14469
Whiteboard: [Perf]Rendering Performance → [PDT+][Perf]Rendering Performance
Putting on [PDT+] radar.
*** Bug 16864 has been marked as a duplicate of this bug. ***
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
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
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.
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.
Blocks: 17062
Blocks: 9489
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: beard → pavlov
Status: ASSIGNED → NEW
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
beard has checked in needed changes in view manager and I have checked in linux
fixes.  This also fixes 17062.
Target Milestone: M14 → M12
Whiteboard: [PDT+][Perf]Rendering Performance; 11/26 → [PDT+][Perf]Rendering Performance; 11/26 12/6: Request verification by reporter
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.
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...)
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 ?
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: