nsCSSRendering::PaintBackground is called too many times




20 years ago
11 years ago


(Reporter: pierre, Assigned: attinasi)



Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




20 years ago
I have done the following test:
- Disable the double buffering in nsViewManager.cpp
- Launch Viewer and display test0.html
- Put a breakpoint on nsCSSRendering::PaintBackground
- Hide a portion of the window to cause a refresh
==> nsCSSRendering::PaintBackground is called twice: once to draw a gray
background, once to draw a white background.

The 1st background is drawn directly by nsHTMLContainerFrame::Paint(), the 2nd
one is called inside the same function when calling PaintChildren().

The problem, I think, is that either nsHTMLContainerFrame or nsCSSRendering
should verify that the 'dirtyRect' portion of the background is not masked by any
children before drawing it.

- The same thing can be noticed with AppRuner and without disabling the double
buffering, it's just easier to debug with Viewer.
- It does not happen with pages like Yahoo that have the default gray background.
- It can particularly hit the performance when displaying animated gifs or when
doing some text selection.

Comment 1

20 years ago
It would be a bad idea to clip the children out before painting the background,
unless the children entirely (or almost entirely) mask the background. You don't
want to have a clipRegion with small holes in it (like in the case of a form with
several widgets) and then do a FillRect(). It would be slower than just doing a
FillRect() without clipping anything.

My suggestion is to just look whether the dirtyRect portion is entirely masked by
the children. If even a small portion is visible, paint the whole thing.

Comment 2

20 years ago
In the Viewer sample cases, the background is painted twice. In AppRunner, it
looks like the background of some objects like the toolbar is painted 3 or 4
times. I may be wrong on that one but I thought it was worth reporting it.


20 years ago
Summary: [Perf] Double background drawing → Double background drawing
Whiteboard: [Perf]

Comment 3

20 years ago
putting on [Perf] radar


19 years ago
Blocks: 8691


19 years ago
Target Milestone: M8 → M11

Comment 4

19 years ago
This no longer seems to be a problem with builds for 08/11.

Comment 5

19 years ago
As far as I know, nothing has been done to fix this. I'm sure it's still an

Comment 6

19 years ago
Moving non-beta 1 items to M15

Comment 7

19 years ago
Reassigning peterl's bugs to myself.

Comment 8

19 years ago
Accepting peterl's bugs that have a Target Milestone

Comment 9

19 years ago
Is this connected to this bug. If so, Adam D. Moss sent in a patch, that was
widely appreciated by the newsgroup .perfomance:
Erno Kuusela wrote:
> also, while scrolling the page, there is some flickering in the area
> where new content is being drawn. this becomes more visible because the
> window background color (gray) is usually different from the web page
> background color, so for example with pages with white background, the
> flickering is between white/gray. perhaps the window background color
> could be changed to the page bg color, or the window system
> could be told not to draw the window background color at all.

This patch does the don't-draw-the-window-background-colour-at-all
thing on UNIX/GTK.  Quick hack last weekend; it should still patch
okay.  Apply it in the widget/src/gtk/ directory.

It has its plusses and minuses but I think that it's an improvement
overall, especially when doing pgup/pgdown and bringing up pop-ups.
Adam D. Moss    . ,,^^    adam@gimp.org    http://www.foxbox.org/

*** nsWindow.cpp.orig   Thu Nov 18 22:29:02 1999
--- nsWindow.cpp        Thu Nov 18 22:40:48 1999
*** 988,994 ****

    // set our background color to make people happy.

!   SetBackgroundColor(NS_RGB(192,192,192));

    // track focus changes if we have a mozarea
    if (mMozArea) {
--- 988,995 ----

    // set our background color to make people happy.

!   //ADM SetBackgroundColor(NS_RGB(192,192,192));
!   gdk_window_set_back_pixmap (mSuperWin->bin_window, NULL, 0);

    // track focus changes if we have a mozarea
    if (mMozArea) {

Comment 10

19 years ago
Pushing my M15 bugs to M16


19 years ago
Target Milestone: M16 → M20


19 years ago
Keywords: perf

Comment 11

19 years ago
Bulk add of "perf" to new keyword field.  This will replace the [PERF] we were
using in the Status Summary field.


19 years ago
Whiteboard: [Perf]

Comment 12

19 years ago
Just a side note...  I believe this is the right bug to append to.  (I'm having
problems finiding other, similar, reports.)  

Under UNIX, Mozilla's window color (I believe called the NULL color) is not
set.  This means that, on slow redraws, mozilla will look transparent as windows
under it get drawn and then mozilla will appear.  

This is simply a user perception problem -- it makes Mozilla look very slow. 
Netscape 4x doesn't have this problem because it sets the NULL color to be the
document's background color, and the NULL color of the form elements to be the
background color of the table the form elements are in.

Bring back the default color!  Please?

Comment 13

19 years ago

Please DON'T bring back the default color. It will cause mozilla to suck
(again!), at opaque move and resize by causing double repainting, blinking, etc...

The repaint speed needs to be improved. This is the only good solution.

Comment 14

19 years ago
Do not report platform-specific problems here. This bug is about optimizing the 
logic we use in Layout to draw backgrounds. Changing the title to 
"nsCSSRendering::PaintBackground is called too many times" from "Double 
background drawing".

Doing new tests on the Mac today, I noticed that PaintBackground() is called 4 
times instead of 2 when the bug was opened last year.
Summary: Double background drawing → nsCSSRendering::PaintBackground is called too many times

Comment 15

19 years ago
CCd attinasi who may found this problem interesting since it is related to 
performance (although Layout performance, not Style).

Comment 16

19 years ago
Target milestone: Future
Reassigned to Marc as it is related to performance.
Assignee: pierre → attinasi
Target Milestone: M20 → Future


19 years ago
Nominating for nsbeta1: performance issue
Keywords: nsbeta1


17 years ago
Blocks: 104166

*** This bug has been marked as a duplicate of 34887 ***
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE

Comment 19

16 years ago
Verified dupe
You need to log in before you can comment on or make changes to this bug.