optimisation for opaque-resize, prevent double painting of background

NEW
Assigned to

Status

()

Core
XUL
16 years ago
15 years ago

People

(Reporter: Marko Macek, Assigned: blizzard)

Tracking

({perf, polish, pp})

Trunk
x86
Linux
perf, polish, pp
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
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.
(Reporter)

Comment 1

16 years ago
Created attachment 52552 [details] [diff] [review]
remove call to gdk_set_background_color in nsWindow::SetBackgroundColor
(Reporter)

Updated

16 years ago
Keywords: patch, pp, review
(Reporter)

Comment 2

16 years ago
fixing cc:
Assignee: blizzard → blizzard
(Reporter)

Comment 3

16 years ago
some more keywords
Keywords: mozilla1.0, perf, polish
(Reporter)

Comment 4

16 years ago
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).
(Assignee)

Comment 5

16 years ago
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.
(Reporter)

Comment 6

16 years ago
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.
(Assignee)

Comment 7

16 years ago
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.
(Reporter)

Comment 8

16 years ago
Yes, you are correct. The problem only occurs with opaque resize (enlarge)...

There is no problem with normal expose events.

Comment 9

16 years ago
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])
(Reporter)

Comment 10

16 years ago
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. 

Comment 11

15 years ago
*** Bug 137758 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.