Rethinking Screensavers

Screensavers are a relict of the last century. They were required to prevent serious hardware damage on CRT screens. This is even implied by the name: a screensaver saves the screen from damage. Now we live in the second decade of the 21st century and the world has changed. I can’t remember when I last saw a CRT computer screen, they have been completely replaced by LCD screens. LCD screens on the other hand don’t show the danger of burn-ins. They don’t need to be “saved”. Nevertheless we still have screensavers.

Nowadays screen savers are used to indicate that the screen has been locked. It is a way to animate the screenlocker. But is that wise at all? Especially in the current time it is extremly important to save power. This means if a screen is locked the screen should turn itself off, the CPU should go into the lowest power state, the compositor should stop repainting the screen, the GPU should go into the lowest power state and so on and so on. But is that possible if a screen saver is active?
The screensaver implementation in the X11 world is rather dated: XScreenSavers were first published in 1992. To be honest: most screensavers even look like being from the last century. Now if a screensaver is active, the CPU has to calculate the animation which implies that it cannot be in idle state. The compositor needs to update the screen which means the compositing engine cannot turn itself off. This implies again that the GPU cannot turn itself in the sleep mode and can cause really heavy load if the compositor needs to constantly do full repaints. Last but not least if the system DPMS is misconfigured the screen will not turn off.
In summary a system will waste power in a situation where it does not need to use any power. It is even possible that (depending on the used screensaver) the system needs more power in the idle state than under usage. Given the world we live in, I want to do something about it. We need to stop wasting power.
The waste of power is not the only disadvantage of the current screen locker system. Several of the existing screensavers have issues as they pre-date the current infrastructure with compositors by years. We have seen that parts of the screen can be leaked which means there can be privacy issues. Even worse is the situation with OpenGL screensavers. They sometimes use ARGB windows and don’t clear the screen (this used to work fine in the pre-compositing era), all areas not repainted by the screensaver are leaked. In case you have a buggy driver it is even likely that either the screensaver or the compositor will not survive that both are used. According to our bug reports this is a common problem. Now driver bugs should be fixed but reality shows: it is not happening.
For the future there is only one obvious solution: the screen locker has to be moved into the compositor. The compositor can ensure that the screen is blanked correctly and not leaking information. If the locker is part of the compositor, it can ensure that the compositing re-paint loop is stopped as long as nothing has to be shown. Only if the unlock dialog is shown the compositor needs to enable repainting and can ensure that everything else except the dialog is blanked. Another small advantage of having the screen locker in the compositor is that we can finally do a nice fade in/out when locking/unlocking the screen.
Removing the screen saver is nothing which will happen for 4.7 as it requires coordinated development. Even if we move screen locking into the compositor we need to ensure that the old architecture is still in place in case KWin is not used or compositing turned off. There is also the Plasmoids on screen locker implementation which is a valid use case and needs to be ported to any new infrastructure. This can become tricky, but I am positive that we will be able to support it. Altogether this is something I want to have for 4.8 and it is something I want to discuss at Tokamak and will make sense to be included in Plasma Active as we there have the control over the compositor which is used and saving as much power as possible is very important for the targeted devices.

=-=-=-=-=
Powered by Blogilo

46 Replies to “Rethinking Screensavers”

  1. This is a great idea! I would like to use my screensaver as a lock at work, but this does not work right now. Even selecting a screensaver from within System Settings will crash the module every time. Not sure why this is. But I agree, screen savers are horribly out-dated.

  2. I fully agree with you!
    We need our computers/smartphones/whatever so save energy when not in use, and avoid crashes on unattended systems.

    Desktop environment defaults should be configured right this way: to save energy and resources. Unless the user doesn’t want so.
    For example, one may prefer running backup jobs or file indexing jobs at high priority when he/she’s not using the system. It could be nice if the system could automatically give higher priority to this kind of jobs when the screen is locked, and lower them when the user unlocks it.

  3. My Main Monitor is still a CRT … i am not that kind of consumer that throws something away even if it still works good.

    1. even for CRT it is more useful to turn off the screen or at least blank it instead of painting random stuff and waste power.

      1. You are totally right on that. I only wanted to say that, as you began your post like there are no CRTs out there in any place, and i think that point is not right.
        Additionally there are more places in the world, where CRTs may be still the majority, not like here.

        1. yes of course I am aware that in less developed countries CRT screens might still be used. But for them saving energy by turning off the screen is even more important and blanking the screen is a sufficient way to protect CRT screens.

          1. > in less developed countries CRT

            YMMD πŸ™‚ no offense, but perhaps you should leave the ivory tower every once in a while and visit offices of the real world. You’d be surprised how much ancient hardware is still in use. As we speak I’m sitting in front of a CRT at a customer’s site in one of these less developed countries (Germany).

            1. and they probably have pluged the CRT to a system able to run compositing? More likely they are still running Windows 2000 on it. With other words: we don’t design our defaults for a legacy minority.

  4. My screensaver uses Plasma and displays some nice images and a clock, I do not see any problem with it, of course it is disabled when using battery or after some minutes. Why should not something useful hide the locked screen (like a clock)?

    1. Read the last paragraph of my post again: I do consider the Plasma screen locker as useful (it’s not a saver!).

  5. It would be even better if instead of locking the screen the PC would go to sleep and wake up instantly if mouse/keyboard is used πŸ™‚

    Right now, on a default install of Fedora 15 all /proc/acpi/wakeup are turnd off so i can’t wake up my system with mouse/keyboard.

    Does GNU/Linux have means to turn off or put devices on low power mode without putting the whole system into sleep mode?

    1. And to add, let’s not go the GNOME way and remove the stuff, let’s do it the KDE way and make it configurable πŸ™‚ There is never one ring to rule them all!

      1. Also to you: read my last paragraph again. We need the legacy system for non-composited systems.

    2. No turning off the complete system is not what you want in general. Let’s consider I’m recompiling my KDE setup and walk away. I want to have the screen locked, but the background job should continue.

      1. To be fair, compiling a new KDE in the background outweighs the energy consumption of a screen saver by far πŸ˜‰ Maybe give examples that fit better for the average user:
        – Amarok is still playing
        – download is still running

        1. yes it was the first one that came to my mind. So a better one: at work I sometimes need to test the server instance running on my dev system from a different workstation. So I have to lock the screen and go to a different room to use the system there.

  6. Awesome stuff. I was recently thinking about screensavers, and thinking more or less the same that you wrote here (like if I should turn the screen off sooner to save power, or if I should replace my dated-looking animation with somethink more pretty and KDE based like plasma widgets). Thanks a lot for thinking in this.

  7. Another issue is that current Wayland plans require moving the screensaver into the compositor, so if you want to support Wayland you will need to move the screensaver into the compositor anyway.

    A question: if you move screensavers into the compositor, and move plasma into the compositor, does that mean we might finally get screensavers-as-wallpapers?

    1. A question: if you move screensavers into the compositor, and move plasma into the compositor, does that mean we might finally get screensavers-as-wallpapers?

      I think that is completly unrelated. Even in the current architecture it should be possible to link against xscreensaver and render the screensaver inside a wallpaper. The better question is: why would you want that? There are clearly better frameworks for animated wallpapers than screensavers.

      1. There may be better frameworks, the advantage is that there are a sizable number of pre-existing screensavers, which means you don’t need to make an entirely new set of animations from scratch.

  8. Allow me to respectfully disagree. I don’t mind if as a default there is no screensaver and all that, but I want to point out two things:

    Not only CRTs have trouble with burning an image, plasmas do too. Also other future display tecnologies might bring this problem back, so I think removing it completely is a bit abrupt.

    Screensavers might have started to “save the screen”, but I think they now are features on their own. For example, if your desktop wallpaper is completely black, it will probably use less power, but people like to put up wallpapers. I think it is the same for screensavers: some people like to see pictures of their family or vacations (their computer when unused pretty much becomes a digital picture frame), others like to put funny mini-games, quotes, a giant clock, videos, fake crash screens, etc etc. I have talked to people that know quite a lot about computers, and they did not know that the screen saver was supposed to save CRTs.

    So, I think having a default as you describe is pretty straightforward, but do consider that people like screensavers as a feature, not just for saving their non-existant CRTs anymore.

    I’d also like to add that a default screensaver can even be a signature for a system: apple’s flurry screensaver or ms’s vista default screensaver are pretty distinctive.

    P.s.: I haven’t used a screensaver on a computer for more than a year.

    1. Not only CRTs have trouble with burning an image, plasmas do too.

      For Plasmas the best solution is turning the screen black. That protects it and saves energy. Having a Plasma TV here, so I know that.

      Also other future display tecnologies might bring this problem back, so I think removing it completely is a bit abrupt.

      Future technologies are future. There is no point in keeping stuff around because it might be needed in the future. If it is needed in the future it can be added again.

      So, I think having a default as you describe is pretty straightforward, but do consider that people like screensavers as a feature, not just for saving their non-existant CRTs anymore.

      Yes it’s always the same, removing functionality will upset some people. Nevertheless we need to provide the best solution for most users and most stakeholders. Saving energy for all users is way more important than a user who wants to see a cat walking on the screen. And an important point: there won’t be the existing screensavers in Wayland.

      1. Well, honestly the “saving users from themselves” is one of the things I don’t like about other, closed OS’s. Defaults are very important, but you should always be able to make your computer do what you want, not what others want.

        I think on this issue, your position is a bit too narrow.
        People do use their computer for more than very critical work. They use it to play games on huge power-hungry GPU’s, get entertained by videos, they leave them on overnight because they might need to ssh into them while they are away, etc.

        It is a trade-off. For example, I accept that my TV and console might be wasting extra power when off, just for the convenience of me not having to get up from the couch to turn them on.

        So I think people should be able to decide if they want the cat walking across the screen or save power. If they want to, they should not be prevented from using the feature.

        1. You could do the photo display stuff using plasma applets on the lock overlay.
          For the people who prefer the traditional screensaver displays what’s to stop them from installing xscreensaver and disabling kwin’s locker (except wayland but that will come whether or not this gets implemented)

          1. I also think that is is a bit aggressive, but as long as there are alternatives like xscreensavers and that they interoperate fine with KDE, I think I can survive this.

            options is what first attracted me to KDE. I understand that some options are too fine grained for normal users, in the sense that for them making a decision means learning things they don’t care about, and I agree that in those cases even well thought defaults are not enough, so most probably the option has to be removed or at least hidden somehow (which already happened).

            but in this case I think that the user is able to make the decision whether he wants the ssaver or not, and if not, a good default is to not have it. again, I think removing screensavers at all, even when their original cause has disappeared but replaced with another one, is a too aggressive simplification.

            as last note: I agree that ssavers must not be run on battery, for instance.

  9. I also agree that the technical neccessarity is no longer given on modern LCD flat panels, but I also agree to those who want to keep them. Yes, it should be configurable for those who want one.

    To save some energy, I have some other ideas:
    KDE has already powerdevil, so why not adding a screen saver control method to it? Some ideas what can be controlled/switched off:
    – Desktop effects can be turned off entirely when the screesaver comes active. That should rather be easy, I think this is just a dbus call
    – Animations, or in general, any draw and paint operations on windows behind the saver, should be stopped. When the screensaver exits, all the visible windows should be repainted. OK, this is difficult, since every application needs to be aware of this, but I think it would already help a lot if web browers would this.
    – When the screensaver blanks or turns off the screen, it should no longer use any graphic resources. I mean, don’t make a fancy 3D animation for a screen in power save mode. This can be done inside the screen saver.
    – Unless someone is doing numbercrunching with CUDA/OpenCL in the background, the graphics hardware is rather bored then, so why not turning it off? OK, this better adressed to the hardware designers and driver coders rather than to KDE people …

    1. what you summarize is exactly why the screen locker has to be inside the compositor. Only the compositor is able to ensure all the things you just highlighted. Turning compositing off through powerdevil makes everything worse as like you said applications are not aware and would continue to render their animations.

      1. My point is “why waste cpu/gpu power for visual effects that nobody can see?” My first idea was just to automatize the “ctrl-alt-f12” for turning on/off the desktop effects.

  10. I wanted to note that some LCD monitors are affected by burn-in and a lot of monitors have a dynamic contrast and if your screen is mostly dark/black, then backlight lamps/LEDs automatically reduce their power, thus saving your power bill. So darkish screensavers can indeed save power πŸ™‚

  11. If you think LCDs are immune to burn-in effects, feel free to take a look at my previous notebook’s screen and think again.

    That said: I never encountered a nice-looking KDE screensaver. IMO they all suck to different degrees. I wouldn’t cry a single tear when they are gone.

  12. Wait so you want the unlock screen code running in the compositor and you’re claiming it will make us safer?

    One of the things I always liked about Xscreensaver was that the screensaver was seperate from the locker, so an individual screensave could crash and the screen would stay locked and I trusted JWZ to not introduce any bugs into the locking code (part of the reason it’s still around from the 90s).

    Putting the locker in the compositor seems like a bad way to solve the fact that it can’t blank the screen, there are other apps that could benefit from blanking the screen and not letting anything else repaint too:

    *Presentations

    *Full screen videos

    *Full screen games (in particular emulators sometimes mess up when painted over)

    *Existing screen lockers

    So would it not make more sense to get klocker or xlocker or any locker or screen app the user wants to call the compositor and say “I’m locking the screen, I’m now the boss nothing else can write to the screen, until I die”

    One of the usefull screensaver plasmoids is the notes one, I would hate for somebody to start writing a note and end up logging in like this https://imgur.com/gallery/fqjnK

    1. Wait so you want the unlock screen code running in the compositor and you’re claiming it will make us safer?

      I nowhere wrote that I would move the “unlock screen code” into the compositor. This is currently already out-of-process, so no need to change that.

  13. That LCD screens do not have the danger of burn-ins is completely incorrect. They are much more resilient to burn-ins but they are not immune.

  14. IIRC, the (green) monochrome monitors need this the most. After those days passed, I started calling them “Idle Screen Animators.” I would agree that locking the screen and partially shutting down the PC is appropriate.

    BUT, I don’t want this when I’m watching a video or listening to an audio stream or file. I find I have to move the mouse occasionally to keep the movie going.

  15. One thing possible w/o this redesign step is to combine blank screen saver with DPMS. I have to configure screen saver and DPMS at 2 different locations. It is senseless to have a blank black screen with backlight still turned on.

  16. As others have already mentioned, lcd’s are susceptible to burn in, and simply blanking them does nothing to revert the issue. It only postpones it.

    On another note, I would like to simply point out that others have different goals. Power usage is not paramount 100% of the time. Take the electric sheep screensaver for example. It’s a distributed computing screensaver where the visuals are calculated by the combined computing power of all of the clients then distributed for playback as mpeg2 movie files. A single core of my CPU runs at 100% whenever my screensaver is active.

    The images generated by this screensaver or beautiful, and, for myself and many others, this is more important to us than a few watts of saved power. I do have DPMS shut off my monitor after an hour or so of the screensaver running as at that point I’m probably not even around to see it.

    Screensavers have evolved to the point where their purpose is simply to make a computer more pleasant to use. They serve the same purpose as the Wobbly Windows kwin effect. Not everyone desires pure utilitarianism. Please try to remember not everyone feels the same and has the same goals and uses for these things, and remember that the use case for a screensaver has evolved.

  17. There’s also the more pressing problem with X that there is no way for a screen-saver window to be treated as a “screen saver” to the window manager, rather we have a nasty pile of hacks right now where in order for a screensaver to function it much grab the input – if it cannot grab the input because a menu is open then it fails to launch. There is also the problem with stacking too – in order for any screensaver to be stacked on top of everything, it spuriously re-stacks its own window, which is no good.

    1. ah forgot about the nice menu problem. The same happens for us if we have a running fullscreen effect.

  18. So you state that we need a fancy compositing manager with a lot of effects like blur and whatnot, which increase power consumption during normal usage, but we don’t need “dated” animated screensavers? Come on… Don’t be a hypocrite – you like working on KWin, and you don’t care that it is less power efficient than purely utilitarian solution, so accept the fact that others may like animated screensavers and don’t care about power consumption either.

    Design your framework with multiple choices in mind, please. Make it plugginable or something.

    1. compositing itself does not require more power but should in certain circumstances even save you power. And in general it is not about providing bling bling but improving the user experience like for example present windows.

      1. And animated screensavers improve “user experience” for a lot of people, including me – for the sheer joy of seeing coworkers stop at my laptop to watch xscreensaver.

  19. Thanks for all your hard work. Looking forward to this stuff and also to run KDE on Wayland.

Comments are closed.