The attached patch will prevent some double painting of window background when the window is resized. Since mozilla uses double buffering it should never tell the X server to paint the background itself. Please review/apply.
Created attachment 52552 [details] [diff] [review] remove call to gdk_set_background_color in nsWindow::SetBackgroundColor
some more keywords
The only call to SetBackgroundColor that triggers this (AFAIK) is in xpfe/appshell/src/nsWebShellWindow.cpp, line 300+ (set to RGB 192,192,192). Perhaps it should be removed instead. (I tried on linux and it has no harmful effect).
That native window isn't ever exposed, except when there's no content area covering it and that almost never happens. In fact, if there wasn't one I would consider it a bug. That code was put in there so that an embedding client that hasn't had a content viewer loaded yet doesn't show nothing.
It is exposed when the window is resized in opaque (live-repaint) mode and slows it down by causing needles repaints. It's also ugly because it makes double buffered repaints slightly less effective.
double buffered repaints only happen on the windows that don't have a background color set so it shouldn't affect those at all. The webshell window is almost always obscured by other windows, except in the case of a toplevel resize where it is stretched and the inner windows aren't resized until the events start to flow.
Yes, you are correct. The problem only occurs with opaque resize (enlarge)... There is no problem with normal expose events.
This doesn't only happen on Linux.. is there an equivalent Windows bug, or is bug 137758 a dup of this? (added attachment 79483 [details])
bug 137758 is probably caused by mozilla being far to slow doing layout and rendering (or being otherwise busy, maybe even swapping). This bug is about painting the background in "gray" once and then drawing the proper content.
*** Bug 137758 has been marked as a duplicate of this bug. ***