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, perf → mozilla0.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. :)
or maybe i'm looking at the wrong file ;)
er, ignore that.
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
You need to log in before you can comment on or make changes to this bug.