Suggestion: separate gfx for s/s and manager

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~~