In my view it is time to consider whether the screensaver should be the same graphic as that displayed on demand from the BOINC manager.

Apologies for cross posting: I am putting this on Ralph, Einstein, and SETI boards so that all the coolest coders see it, but the *really* cool will see it 3x. I'm not currently on the BOINC forums/maillists so if someone would like to copy it there that is fine.

A screensaver should be pretty but use very little code. Most of the time it will be running it will not be being looked at, and if it uses a lot of crunch time that will only hurt the project. It should not need user input because that conflicts with the fact that user input is supposed to interrupt the s/s completely and drop the user back into Word or whatever. A s/s should not use much memory either, as this makes it all the more likely that the user will experience a page-fault delay when they want to get back to Word.

In contrast, when the user is hands-on, they want to look inside the model, see what it is doing now, rotate the protein, etc etc, all of which takes a fair amount of cpu time and all of which are much more entertaining if interactive and all of which typically gobble up more memory than the actual crunching.

And a user who has being doing that will be less likely to even notice if there is a page file delay afterwards.

There would be two ways to engineer this, depending whter BOINC or a project takes it up first.

If BOINC then a future release of BOINC should be able to cope with there being different programs loaded as the s/s and as the "show graphics" response. Projects which still offer the same would simply provide the same program in both cases.

If a project then the graphics part of the app should iteself have a test for "am I a s/s" early in the code and before the big chunky stuff is loaded.

As a concession to those liking interactive s/s, there could be a cross-project standard that (say) ctrl-G during the s/s switched into advanced graphics mode. Perhaps this could even be the only key/mouse stroke responded to while acting as a s/s.

After the usual s/s delay, the advanced graphics would lapse back to s/s mode, speeding up the crunching. The LHC s/s already does this, lapsing into a more efficient mode once the user stops prodding it.

Just an idea for the future - clearly this is not on the urgent list but I do suggest it is worth thinking about in the longer term. I wonder how many protein decoys go untried, how many et's fail to phone home, how long Albert suffers with no waves in his gravy, while all the time the s/s is playing to an absent user?

River~~

---