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. Notes: - 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.

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.

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.

putting on [Perf] radar

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

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

Moving non-beta 1 items to M15

Reassigning peterl's bugs to myself.

Accepting peterl's bugs that have a Target Milestone

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) {

Pushing my M15 bugs to M16

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

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?

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.

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.

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

Target milestone: Future Reassigned to Marc as it is related to performance.

Nominating for nsbeta1: performance issue

*** This bug has been marked as a duplicate of 34887 ***

Verified dupe