PDA

View Full Version : Suppress screensaver if brightness ==0



Triode
2005-07-03, 10:15
Hi,

Max Spicer suggested that a screensaver should not run if brightness is set to 0 in power off mode - to minimse network bandwidth
and server activity when in this state. [bug 1745] (See discuss list for more details of Max's requirements, specific to Rss) I
think the attached achieves Max's requirements.

I would like feedback from people with more experience of the server history as I've made one change to the old code: 'off' mode now
returns a blank screen rather than dateTime in its lines function.

This avoids the brief clock display before switching into a screensaver and relies on dateTime screensaver for the clock display.
Was there any other reason for off mode to return dateTime or is this just historical??

Adrian

max.spicer
2005-07-03, 11:59
Was there ever a solution to the fact that posts coming via the newsgroups/mailing lists don't keep there attachments when received on the forums? No sign of any attachment from my vBulletin point of view. :-(

Max


Hi,

Max Spicer suggested that a screensaver should not run if brightness is set to 0 in power off mode - to minimse network bandwidth
and server activity when in this state. [bug 1745] (See discuss list for more details of Max's requirements, specific to Rss) I
think the attached achieves Max's requirements.

I would like feedback from people with more experience of the server history as I've made one change to the old code: 'off' mode now
returns a blank screen rather than dateTime in its lines function.

This avoids the brief clock display before switching into a screensaver and relies on dateTime screensaver for the clock display.
Was there any other reason for off mode to return dateTime or is this just historical??

Adrian

Triode
2005-07-03, 14:11
Let me try again with a vBulletin attachement (assuming I can make it work...)

Triode
2005-07-03, 17:12
> I would like feedback from people with more experience of the server history as I've made one change to the old code: 'off' mode
> now
> returns a blank screen rather than dateTime in its lines function.
>

Updated version which does the same thing for brightness == 0 in on mode. This changes the lines function to one which returns a
blank screen when brightness is 0.

I've introduced a new mode 'blank' with its own map in Default.map for this so that buttons can be passed back when pressed after
the brightness is changed.
Did I do this in the right way and have I trapped all the right buttons? [first time I've looked at this bit of code]

Adrian

dean
2005-07-03, 23:01
I'm confused by this. Isn't the bug that the screensaver shouldn't
kick in if the brightness is zero? Seems like a much simpler change
(and less risky as we get closer to 6.1...)


On Jul 3, 2005, at 5:12 PM, Triode wrote:

>> I would like feedback from people with more experience of the
>> server history as I've made one change to the old code: 'off' mode
>> now
>> returns a blank screen rather than dateTime in its lines function.
>>
>>
>
> Updated version which does the same thing for brightness == 0 in on
> mode. This changes the lines function to one which returns a blank
> screen when brightness is 0.
>
> I've introduced a new mode 'blank' with its own map in Default.map
> for this so that buttons can be passed back when pressed after the
> brightness is changed.
> Did I do this in the right way and have I trapped all the right
> buttons? [first time I've looked at this bit of code]
>
> Adrian
>
> <saver2.diff>
>

Triode
2005-07-04, 03:15
Dean,

Max also wants to start and stop the screen saver just by changing brightness. So he can select Rss and then actually stop it being
involked and sending stuff to the player by setting brightness to 0. However when he wants to read it he then just wants to change
the brightness. The first patch does this for off mode only. I think this latter patch is more general in that it suppresses
updates and animiation if brightness is set to 0 by pushing into a new mode.

I was actually thinking this would miss 6.1, but perhaps the first patch I posted which is much simpler and only does this for 'off'
mode could be considered?

Adrian

> I'm confused by this. Isn't the bug that the screensaver shouldn't kick in if the brightness is zero? Seems like a much simpler
> change (and less risky as we get closer to 6.1...)
>

max.spicer
2005-07-04, 05:52
Missing from vBulletin again. Could you attach the patches to the bug instead? I'd have thought that would be a more sensible holding place for them anyway.

Max


>
Updated version which does the same thing for brightness == 0 in on mode. This changes the lines function to one which returns a
blank screen when brightness is 0.

I've introduced a new mode 'blank' with its own map in Default.map for this so that buttons can be passed back when pressed after
the brightness is changed.
Did I do this in the right way and have I trapped all the right buttons? [first time I've looked at this bit of code]

Adrian

dean
2005-07-04, 08:13
I'm not sure we want to overload the brightness button to also mean
"pause the screensaver".

The brightness button shouldn't affect the screensaver. Indeed, a
new brightness setting has recently been added so that you can adjust
the
screensaver brightness while the screensaver is ticking. This makes
three independent brightness settings (powered on, powered off,
screensaver).

Optimizing CPU and network performance to not calculate or send
screen updates when the display is dimmed is a noble goal, but the
end-user behavior probably shouldn't change.


On Jul 4, 2005, at 3:15 AM, Triode wrote:

> Dean,
>
> Max also wants to start and stop the screen saver just by changing
> brightness. So he can select Rss and then actually stop it being
> involked and sending stuff to the player by setting brightness to
> 0. However when he wants to read it he then just wants to change
> the brightness. The first patch does this for off mode only. I
> think this latter patch is more general in that it suppresses
> updates and animiation if brightness is set to 0 by pushing into a
> new mode.
>
> I was actually thinking this would miss 6.1, but perhaps the first
> patch I posted which is much simpler and only does this for 'off'
> mode could be considered?
>
> Adrian
>
>
>> I'm confused by this. Isn't the bug that the screensaver
>> shouldn't kick in if the brightness is zero? Seems like a much
>> simpler change (and less risky as we get closer to 6.1...)
>>
>>
>
>

Triode
2005-07-04, 08:51
Ok lets leave for until after 6.1.

I would like feedback from Max anyway - any comments Max?

I must admit to being reasonably happy with the power off one as wouldn't expect users to notice any difference. It is likely they
are using date time or Rss screensavers - for date time you can notice no difference. For Rss, it does go back to the start, but if
users are diming the display to zero for a reason they are unlikely to notice this.

Adrian

> I'm not sure we want to overload the brightness button to also mean "pause the screensaver".
>
> The brightness button shouldn't affect the screensaver. Indeed, a new brightness setting has recently been added so that you can
> adjust the
> screensaver brightness while the screensaver is ticking. This makes three independent brightness settings (powered on, powered
> off, screensaver).
>
> Optimizing CPU and network performance to not calculate or send screen updates when the display is dimmed is a noble goal, but
> the end-user behavior probably shouldn't change.

sbjaerum
2005-07-04, 08:59
Ok lets leave for until after 6.1.

I would like feedback from Max anyway - any comments Max?

I must admit to being reasonably happy with the power off one as wouldn't expect users to notice any difference. It is likely they
are using date time or Rss screensavers - for date time you can notice no difference. For Rss, it does go back to the start, but if
users are diming the display to zero for a reason they are unlikely to notice this.

Adrian

> I'm not sure we want to overload the brightness button to also mean "pause the screensaver".
>
> The brightness button shouldn't affect the screensaver. Indeed, a new brightness setting has recently been added so that you can
> adjust the
> screensaver brightness while the screensaver is ticking. This makes three independent brightness settings (powered on, powered
> off, screensaver).
>
> Optimizing CPU and network performance to not calculate or send screen updates when the display is dimmed is a noble goal, but
> the end-user behavior probably shouldn't change.

I agree with Adrian. I can't see that the end-user behavior is changed, just a reduction in CPU and network bandwidth.

Steinar

max.spicer
2005-07-04, 09:14
We're not really overloading the brightness button, merely adding some common-sense logic to its implementation. If you turn off the display of your machine by setting its brightness to 0, it makes no sense for the server to continue computing a load of scrolling data and to send it to the machine at a fairly high cost in network bandwith (so high that it can crash my crap router!).

If the current patch really does just pause the screensaver when brightness==0, how is the end-user experience really changed? I can see it would be a problem if the screensaver restarted when you went from brightness==0 to 3, as this would be a pain for someone who is just cycling through the brightness levels. However, if the screensaver merely pauses whilst brightness==0, then you've got an ideal behaviour. How many people would really want to see that the screensaver has moved on in the time that they couldn't see it?

Max



I'm not sure we want to overload the brightness button to also mean
"pause the screensaver".

The brightness button shouldn't affect the screensaver. Indeed, a
new brightness setting has recently been added so that you can adjust
the
screensaver brightness while the screensaver is ticking. This makes
three independent brightness settings (powered on, powered off,
screensaver).

Optimizing CPU and network performance to not calculate or send
screen updates when the display is dimmed is a noble goal, but the
end-user behavior probably shouldn't change.

sbjaerum
2005-07-04, 12:33
If the current patch really does just pause the screensaver when brightness==0, how is the end-user experience really changed? I can see it would be a problem if the screensaver restarted when you went from brightness==0 to 3, as this would be a pain for someone who is just cycling through the brightness levels.




For Rss, it does go back to the start, but if
users are diming the display to zero for a reason they are unlikely to notice this.


Well, because the current patch does not pause, but restarts the screensaver when changing from brightness==0, I guess the behavior is not yet transparent to the end-user. Is it feasible to just pause the screensaver and resume (instead of restart) when changing from brightness==0?

Steinar

max.spicer
2005-07-04, 12:54
Yes, I've only just got around to applying the patch so have only just realised that it does in fact restart, not pause the screensaver. I can see Dean's point now. That said, I still prefer the behaviour of the current patch to the "swamp the wireless network" behaviour without the patch.

Testing the 2nd patch is a bit harder as my activity lights are flashing like crazy anyway whilst playing music. I've noticed that a scroll of the now playing info now restarts when I cycle through brightness 0 to high though, so it's definitely taking effect.

Max


Well, because the current patch does not pause, but restarts the screensaver when changing from brightness==0, I guess the behavior is not yet transparent to the end-user. Is it feasible to just pause the screensaver and resume (instead of restart) when changing from brightness==0?

Steinar

Triode
2005-07-04, 13:05
I'm not convinced it is possible to "pause" a screensaver - hence the solution in the patch which changes display mode to a mode
which results in a blank screen.

Yes it will result in the screensaver restarting when brightness is changed from 0, but this will only be noticable on a screensaver
which stores state or does scrolling.

Lets continue to discuss here with Dean, but don't expect anything in 6.1 [you can apply your own patches!]

Adrian

> Yes, I've only just got around to applying the patch so have only just
> realised that it does in fact restart, not pause the screensaver. I
> can see Dean's point now. That said, I still prefer the behaviour of
> the current patch to the "swamp the wireless network" behaviour without
> the patch.
>
> Testing the 2nd patch is a bit harder as my activity lights are
> flashing like crazy anyway whilst playing music. I've noticed that a
> scroll of the now playing info now restarts when I cycle through
> brightness 0 to high though, so it's definitely taking effect.
>
> Max
>
> sbjaerum Wrote:
>> Well, because the current patch does not pause, but restarts the
>> screensaver when changing from brightness==0, I guess the behavior is
>> not yet transparent to the end-user. Is it feasible to just pause the
>> screensaver and resume (instead of restart) when changing from
>> brightness==0?

sbjaerum
2005-07-04, 13:28
My preference is clear, the advantage of bandwidth reduction clearly outweighs the minor disadvantage of a restart when changing brightness from 0.

SqueezeNetwork also has a screensaver mode. The bandwidth reduction provided with this patch fits perfectly with the SQN architecture where the screensaver data are transferred over Internet.

I fully understand that at some point before a release there has to be a feature freeze, but in my opinion the concept of this patch is good, and I hope it will be part of the next release.

Steinar



I'm not convinced it is possible to "pause" a screensaver - hence the solution in the patch which changes display mode to a mode
which results in a blank screen.

Yes it will result in the screensaver restarting when brightness is changed from 0, but this will only be noticable on a screensaver
which stores state or does scrolling.

Lets continue to discuss here with Dean, but don't expect anything in 6.1 [you can apply your own patches!]

Adrian

> Yes, I've only just got around to applying the patch so have only just
> realised that it does in fact restart, not pause the screensaver. I
> can see Dean's point now. That said, I still prefer the behaviour of
> the current patch to the "swamp the wireless network" behaviour without
> the patch.
>
> Testing the 2nd patch is a bit harder as my activity lights are
> flashing like crazy anyway whilst playing music. I've noticed that a
> scroll of the now playing info now restarts when I cycle through
> brightness 0 to high though, so it's definitely taking effect.
>
> Max
>
> sbjaerum Wrote:
>> Well, because the current patch does not pause, but restarts the
>> screensaver when changing from brightness==0, I guess the behavior is
>> not yet transparent to the end-user. Is it feasible to just pause the
>> screensaver and resume (instead of restart) when changing from
>> brightness==0?

Grotus
2005-07-05, 08:11
dean blackketter wrote:
> Optimizing CPU and network performance to not calculate or send screen
> updates when the display is dimmed is a noble goal, but the end-user
> behavior probably shouldn't change.

I agree with Dean here. Plus I think you targeted the wrong spot. I
believe that the display update should still be calculated, just not
sent if the player brightness is 0. If the user is using Shadowplay to
redirect the screen output to a different player, it shouldn't matter if
the original player has its brightness set to 0.

The two places I would target would be Slim::Hardware::VFD::vfdUpdate
and Slim::Player::SqueezeboxG::sendFrame (and modify
Slim::Player::SqueezeboxG::scrollUpdateDisplay to use sendFrame rather
than Slim::Networking::Select::writeNoBlock).

Triode
2005-07-05, 10:48
> I agree with Dean here. Plus I think you targeted the wrong spot. I believe that the display update should still be calculated,
> just not sent if the player brightness is 0. If the user is using Shadowplay to redirect the screen output to a different player,
> it shouldn't matter if the original player has its brightness set to 0.
>
> The two places I would target would be Slim::Hardware::VFD::vfdUpdate and Slim::Player::SqueezeboxG::sendFrame (and modify
> Slim::Player::SqueezeboxG::scrollUpdateDisplay to use sendFrame rather than Slim::Networking::Select::writeNoBlock).

Lets debate after 6.1 is out. However I would say that if scrolling is going at a fast rate then I do agree with Max that
calculating ~ 100 fames per second (which is what I and others doing smooth scrolling are likely to use it) is wastefull.

Dropping at the display phase is the easy answer, but does need to maintain a periodic update for non SB2 players. Hence the
simplicity of adding a node mode as this can be called as appropriate for the player [SB2 will not, others will]

BTW - scrolling on a graphic player bypasses sendFrame for to avoid the additional string copies involved - this did have a
noticable benefit when I benchmarked it and seems reasonable given that I directly check the write Q first to ensure I don't congest
it and so am reaching into this api anyway..

Adrian

kdf
2005-07-05, 11:17
I'm sorry, but this is all sounding like bigtime feature creep to me. This is
an audio player. Why so much overhauling to make this a news reader? If its
about conserving bandwidth, a blank screensaver plugin would do a great job.

as I see it, there are currently 57 higher priorities, so I'll say no more until
post-6.1
-kdf

max.spicer
2005-07-05, 12:24
Agreed, I think everyone involved is more than happy to leave this for the future.

Max

PS Why so much overhauling to make a news reader? Because you can! ;-)


I'm sorry, but this is all sounding like bigtime feature creep to me. This is
an audio player. Why so much overhauling to make this a news reader? If its
about conserving bandwidth, a blank screensaver plugin would do a great job.

as I see it, there are currently 57 higher priorities, so I'll say no more until
post-6.1
-kdf