Open Bug 52280 Opened 24 years ago Updated 2 years ago

use backing store to avoid unnecessary expose events

Categories

(Core :: XUL, defect, P3)

x86
Linux
defect

Tracking

()

Future

People

(Reporter: dmosedale, Unassigned)

Details

(Whiteboard: [need info][wgate])

http://www.rahul.net/kenton/perf.html#BackingStore has info on this, as well as
other perf stuff.
Very easy performance win.
Keywords: nsbeta3, perf
Well, there are bloat considerations here. I think that at the moment the
performance of mozilla is pretty adequate, whereas the memory requirements are
far to huge.

I use/develop mozilla daily using remote X display only, and it's pretty decent.
I disagree that the current perf is adequate.  The lack of backing store and 
resultant window smear that happens when you drag a window off the top of a 
mozilla windows looks really unprofessional.
Component: XP Apps: GUI Features → XP Toolkit/Widgets
QA Contact: sairuh → jrgm
need info: what specific user-visible operations have unacceptable performance,
that would be fixed by this?
Whiteboard: [need info]
Nominating for mozilla 0.8.

Peter: as I understand it, anytime a window is obscured by another window,
iconified, or switched to a different virtual desktop on Unix (all very common
operations), the X server currently discards all the bits that have been
obscured.  When it is unobscured, the server than sends an expose event to
mozilla, forcing mozilla to redraw that region.  If backing store were on, the
server would save those bits and restore them instantly at expose time without
triggering a mozilla event or roundtrips to the X server.

Anyone else: please correct me on any details that I've got wrong.
Keywords: nsbeta3, perfmozilla0.8
One of the interesting side effects of using a backing store is that as you
scroll a window the image contents are not removed.  What you get is unlimited
memory growth.  When I did turn it on my X server grew to over 100 meg in a very
short amount of time.

I'm not saying that this isn't a bad idea.  I'm saying there's a lot to make it
work right and not destroy people's machines. :)
Keywords: mozilla0.9
Keywords: mozilla0.8.1
Keywords: mozilla0.8
or maybe i'm looking at the wrong file ;)
er, ignore that.
Target Milestone: --- → Future
Getting backing store used (optionally) would be nice; depending on your desktop
layout and how much RAM your machine has it may be significantly faster, and
would avoid the disturbing "halls of mirrors" effect Mozilla currently has.

That being said, Mozilla 0.9.1 is the first Mozilla that I find usable for
everyday work, and I'm very happy about that.  Good job everyone!
blizzard: Backing store should not use unlimited memory even when scrolling.
Are you sure about this?  The backing store code is in gdk_superwin_new() in
gdksuperwin.c; all the code is there but the setting of it to when_mapped is
commented out.

Backing store should use no more memory than the size of the window.

Backing store makes a BIG difference for someone using a remote X connection;
they'll normally be very happy to trade an extra copy of the window (at most)
for not having to redraw it across a modem or cable or DSL connection.
Whiteboard: [need info] → [need info][wgate]
The problem is that the backing store is saved for the entire size of the
scrolling inner window.  This means that as you scroll, the pixmap that's used
as the backing store continues to grow and grow and grow and isn't shrunk.  I
remember the X server easily swelling to over 100 meg just from scrolling a
really long bug.
I don't think there is a scrolling inner window (any more?). When you scroll, we
explicitly reposition the widgets contained inside the scrollport. That's why my
GTK widget-wrapping fix works (nudge, nudge).
blizzard, perhaps the problems you saw were back in the days when we relied on
native scrollbars. We don't use those anymore except for listboxes and
comboboxes --- and those uses have to go away sooner or later, too.
There certainly is a scrolling inner window.  At least, there had better be
unless someone re-architected the entire way the browser works with gtk while I
wasn't looking.
Native scrollbars don't have anything to do this this.
Perhaps you keep a scrolling inner widget internal to the widget/src/gtk code (I
couldn't quite figure out what all the different GtkWidget pointers were for),
but no such widget shows up in the nsIWidget hierarchy.

If I'm wrong, then I would like to know how my GTK 16-bit-coordinate-wrapping
fix works :-).

If you do keep an internal scrolling inner widget around, I wonder why we need it.
It's certainly internal to the code.  Each nsWindow is two X windows, an inner
window and a clipping window.  It's the only reason that we have even slightly
sane scrolling on unix.  That's what all the superwin crap is.

I never got to see your 16 bit code, so I'm wondering how it works, too.  During
a scroll it should find all of the windows that come into visibitility and map
them and unmap ones that shouldn't.  You only need to do that during a scroll,
obviously.
BTW, I've played with this a bit.

It generally works.  I don't know if there are memory-use regressions.  The
issues I've seen:

exposed areas are initially drawn in black (backfill I assume)
CC (scrolling list) widgets in bugs don't always refresh when you hit "home"
while looking at the bottom of a bugzilla page (the box is left gray).
Given Chris's last comment I can see why it'd be a memory hog (for the XServer).

For wgate, we'll use save_under for the overlaying window, which is temporary. 
Chris, would save_under cause the same sort of effect?  I believe xservers
handle save_under by temporarily turning on backing_store (or a variant thereof)
for obscured windows.
So widgets in the scrolled area are parented to the clipping window and the
scrolling inner area is only used to get fast scrolling blits, and doesn't have
any widget children of its own? I guess that would be compatible with what I've
seen. So X/GTK doesn't give you a Scroll(aRect, aDelta) function?

I thought I sent you a review request for the 16-bit fixup code. Anyway, it's
bug 126592. The code seems to cause intermittent problems with popups so I need
to debug it some more before it gets really reviewed. However, the concept seems
to be sound.
I think that save_under is relatively safe.  Some window managers use it iirc.

As for window scrolling - no, child windows are parented to the inner window,
not the clipping window.  This is so that when you want to scroll all of the
painted areas and the native widgets all move at the same time.  X does not have
any kind of Scroll() function, which sucks and is why we use this method.
I don't see how that squares with this loop here:
http://lxr.mozilla.org/seamonkey/source/widget/src/gtk/nsWindow.cpp#2253

This loop is moving all the child widgets explicitly after a scroll operation,
isn't it?
No, it's not.  It's just updating the bounds with the new window positions. 
There's no actual movement going on.
oooooh. I get it. thanks.

Still, look at this:
http://lxr.mozilla.org/seamonkey/source/view/src/nsScrollPortView.cpp#345
This really does move the widgets, without scrolling the inner window, because
it's called when the view system just decided to repaint instead of blit, and we
never call your Scroll routine.

Hmm, it's not at all clear how this interacts with the inner window stuff when
both methods are used on the same scroll port.
Assignee: pavlov → jag
QA Contact: jrgmorrison → xptoolkit.widgets
Assignee: jag → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.