Hi, I've just got to ask this, please forgive me if it is only marginally on-topic for this list.
Back when I started using X11 (late 80's, Ultrix, X11R3), turning on save-unders and backing store was an essential performance tuning step, that drastically improved the perceived "speed" of the desktop (e.g. disappearing menus exposed the underlying window instantly, without it having to be re-drawn).
I've used save-unders and backing store ever since. Which also means that ever since starting to use RH desktops I had to turn it on manually, by editing the X command line in [gx]dm.conf. All RH and FC desktops I've used so far disable backing store (and at the same time save-unders - the two seem to be inextricably linked) by default.
Why is that so? I have to admit that with modern hardware the perceived speed-up is small and may even be entirely based on self-suggestion. However, I'd like to understand the pros and cons of turning on backing store with modern X servers and on modern hardware.
Cheers Steffen.
With that, do you get "streaks" and "smears" when you drag a window?
Hmm.. maybe an idea to turn it on then. How do i do it? RTFM? (man xorg.conf ?)
What do you mean with "modern hardware"?
tir, 05.10.2004 kl. 03.34 skrev Steffen Kluge:
Hi, I've just got to ask this, please forgive me if it is only marginally on-topic for this list.
Back when I started using X11 (late 80's, Ultrix, X11R3), turning on save-unders and backing store was an essential performance tuning step, that drastically improved the perceived "speed" of the desktop (e.g. disappearing menus exposed the underlying window instantly, without it having to be re-drawn).
I've used save-unders and backing store ever since. Which also means that ever since starting to use RH desktops I had to turn it on manually, by editing the X command line in [gx]dm.conf. All RH and FC desktops I've used so far disable backing store (and at the same time save-unders - the two seem to be inextricably linked) by default.
Why is that so? I have to admit that with modern hardware the perceived speed-up is small and may even be entirely based on self-suggestion. However, I'd like to understand the pros and cons of turning on backing store with modern X servers and on modern hardware.
Cheers Steffen.
-- Fedora-desktop-list mailing list Fedora-desktop-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-desktop-list
On Tue, 2004-10-05 at 16:17 +0200, Kyrre Ness Sjobak wrote:
With that, do you get "streaks" and "smears" when you drag a window?
Hmm.. maybe an idea to turn it on then. How do i do it? RTFM? (man xorg.conf ?)
I do know how to turn it on. My point was that it *always* seems to be disabled by default, and I feel I'm always swimming against the current by stubbornly turning it on. I just want to understand the rationale behind not having it on by default.
Cheers Steffen.
What do you mean with "modern hardware"?
I should have said "contemporary" rather than "modern". What I mean is, say, an Athlon XP 2600+ 1GB RAM, NVidia GeForce FX5200 128MB. Rather cheap but reasonably fast stuff.
Cheers Steffen.
ons, 06.10.2004 kl. 08.28 skrev Steffen Kluge:
On Tue, 2004-10-05 at 16:17 +0200, Kyrre Ness Sjobak wrote:
With that, do you get "streaks" and "smears" when you drag a window?
Hmm.. maybe an idea to turn it on then. How do i do it? RTFM? (man xorg.conf ?)
I do know how to turn it on. My point was that it *always* seems to be disabled by default, and I feel I'm always swimming against the current by stubbornly turning it on. I just want to understand the rationale behind not having it on by default.
Cheers Steffen.
What do you mean with "modern hardware"?
I should have said "contemporary" rather than "modern". What I mean is, say, an Athlon XP 2600+ 1GB RAM, NVidia GeForce FX5200 128MB. Rather cheap but reasonably fast stuff.
Cheers Steffen.
Just for the record, my main computer (which i am writing this from) is an 650 Mhz P3 with 348 MB ram and a geforce 2 mx PCI. And i dont plan to switch in the immediate future - unless some of my friends really get me in on doom 3, and i get a lot of money. Neither seems very likely.
-- Fedora-desktop-list mailing list Fedora-desktop-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-desktop-list
On Tue, 2004-10-05 at 11:34 +1000, Steffen Kluge wrote:
Hi, I've just got to ask this, please forgive me if it is only marginally on-topic for this list.
Back when I started using X11 (late 80's, Ultrix, X11R3), turning on save-unders and backing store was an essential performance tuning step, that drastically improved the perceived "speed" of the desktop (e.g. disappearing menus exposed the underlying window instantly, without it having to be re-drawn).
I've used save-unders and backing store ever since. Which also means that ever since starting to use RH desktops I had to turn it on manually, by editing the X command line in [gx]dm.conf. All RH and FC desktops I've used so far disable backing store (and at the same time save-unders - the two seem to be inextricably linked) by default.
Why is that so? I have to admit that with modern hardware the perceived speed-up is small and may even be entirely based on self-suggestion. However, I'd like to understand the pros and cons of turning on backing store with modern X servers and on modern hardware.
Well, the biggest problem with backing store is that it is per-window not per *toplevel* window. In X, toplevel windows can have subwindows (try xwininfo -tree).
In certain circumstances, X can end up storing huge amounts of entirely useless pixel data for subwindows because it mistakes them for obscured toplevels.
Save unders are broken because they are just a quick hack that works by turning on backing store for the windows under the popup.
The COMPOSITE extension is a much better way of doing backing stored windows. It's slightly more expensive than classic save unders because it saves the entire window, not just the obscured parts, but it's a lot more robust, and allows doing a lot more (previews in your pager, alpha transparency, etc.) We'll probably have it on by default by the FC5 timescale.
Regards, Owen
tir, 05.10.2004 kl. 21.15 skrev Owen Taylor:
On Tue, 2004-10-05 at 11:34 +1000, Steffen Kluge wrote:
Hi, I've just got to ask this, please forgive me if it is only marginally on-topic for this list.
Back when I started using X11 (late 80's, Ultrix, X11R3), turning on save-unders and backing store was an essential performance tuning step, that drastically improved the perceived "speed" of the desktop (e.g. disappearing menus exposed the underlying window instantly, without it having to be re-drawn).
I've used save-unders and backing store ever since. Which also means that ever since starting to use RH desktops I had to turn it on manually, by editing the X command line in [gx]dm.conf. All RH and FC desktops I've used so far disable backing store (and at the same time save-unders - the two seem to be inextricably linked) by default.
Why is that so? I have to admit that with modern hardware the perceived speed-up is small and may even be entirely based on self-suggestion. However, I'd like to understand the pros and cons of turning on backing store with modern X servers and on modern hardware.
Well, the biggest problem with backing store is that it is per-window not per *toplevel* window. In X, toplevel windows can have subwindows (try xwininfo -tree).
In certain circumstances, X can end up storing huge amounts of entirely useless pixel data for subwindows because it mistakes them for obscured toplevels.
Save unders are broken because they are just a quick hack that works by turning on backing store for the windows under the popup.
The COMPOSITE extension is a much better way of doing backing stored windows. It's slightly more expensive than classic save unders because it saves the entire window, not just the obscured parts, but it's a lot more robust, and allows doing a lot more (previews in your pager, alpha transparency, etc.) We'll probably have it on by default by the FC5 timescale.
Regards, Owen
-- Fedora-desktop-list mailing list Fedora-desktop-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-desktop-list
That's a looong wait. About a year or so... But, yes, i'm really looking foreward to it :P
On Tue, 2004-10-05 at 15:15 -0400, Owen Taylor wrote:
Well, the biggest problem with backing store is that it is per-window not per *toplevel* window. In X, toplevel windows can have subwindows
Hmm, interesting. It seems, though, that the X11 forefathers have thought of that, to a degree. There used to be (still are?) the "WhenMapped" and "WhenUseful" backing store attributes. There still seems to be the -wm server switch, turning on "WhenMapped" for all windows.
In certain circumstances, X can end up storing huge amounts of entirely useless pixel data for subwindows because it mistakes them for obscured toplevels.
How much of an issue is this? I vaguely remember reading once that backing store uses off-screen frame buffer memory (there should be plenty of that on a 128MB graphics card running at 1280x1024). Does backing store actually affect the X server memory footprint? Then again, doesn't the reported memory footprint of the X server contain all the mapped in frame buffer memory as well? The more I think about it the more I realise my utter ignorance in all of this...
Cheers Steffen.
On Wed, 2004-10-06 at 16:38 +1000, Steffen Kluge wrote:
On Tue, 2004-10-05 at 15:15 -0400, Owen Taylor wrote:
Well, the biggest problem with backing store is that it is per-window not per *toplevel* window. In X, toplevel windows can have subwindows
Hmm, interesting. It seems, though, that the X11 forefathers have thought of that, to a degree. There used to be (still are?) the "WhenMapped" and "WhenUseful" backing store attributes. There still seems to be the -wm server switch, turning on "WhenMapped" for all windows.
This doesn't really help - you want to backing store the *visible* portions of subwindows, what you don't want to do is to backing store portions of subwindows that are obscured by other subwindows.
In certain circumstances, X can end up storing huge amounts of entirely useless pixel data for subwindows because it mistakes them for obscured toplevels.
How much of an issue is this? I vaguely remember reading once that backing store uses off-screen frame buffer memory (there should be plenty of that on a 128MB graphics card running at 1280x1024). Does backing store actually affect the X server memory footprint? Then again, doesn't the reported memory footprint of the X server contain all the mapped in frame buffer memory as well? The more I think about it the more I realise my utter ignorance in all of this...
Imagine a 10,000 item list that is 150,000 pixels by 1000 pixels - e.g., 450 megs of memory.
Under some circumstances, the X backing store code can be fooled into backing storing the *entire list*.
Regards, Owen
On Wed, 2004-10-06 at 14:59 -0400, Dan Williams wrote:
On Wed, 2004-10-06 at 14:47 -0400, Owen Taylor wrote:
Imagine a 10,000 item list that is 150,000 pixels by 1000 pixels - e.g., 450 megs of memory.
Apple uses backing store compression in 10.2 and later. Why could that not be used in X?
It could, but the new COMPOSITE etc. work will make the old backing store feature obsolete anyhow.
Havoc
But backing store works NOW. Composite don't.
lør, 09.10.2004 kl. 00.03 skrev Havoc Pennington:
On Wed, 2004-10-06 at 14:59 -0400, Dan Williams wrote:
On Wed, 2004-10-06 at 14:47 -0400, Owen Taylor wrote:
Imagine a 10,000 item list that is 150,000 pixels by 1000 pixels - e.g., 450 megs of memory.
Apple uses backing store compression in 10.2 and later. Why could that not be used in X?
It could, but the new COMPOSITE etc. work will make the old backing store feature obsolete anyhow.
Havoc
On Sat, 2004-10-09 at 14:01 +0200, Kyrre Ness Sjobak wrote:
But backing store works NOW. Composite don't.
It doesn't support compression or avoid the huge-memory-usage cases now. Those things aren't trivial to fix, and the people that would fix them are working on composite instead. Composite is not any more blue-sky or long-term than fixing backing store would be.
Havoc
Havoc Pennington wrote:
It could, but the new COMPOSITE etc. work will make the old backing store feature obsolete anyhow.
I think the idea of backing store compresison will be relevant for COMPOSITE as well. COMPOSITE is going to require lots and lots of video memory, or perhaps even system memory in some cases.
Soeren
desktop@lists.fedoraproject.org
-
Dan Williams -
Havoc Pennington -
Kyrre Ness Sjobak -
Owen Taylor -
Soren Pedersen -
Steffen Kluge