Thoughts on screen update code

[Triode]

Hi,

I've been looking at the screen update/display code and wanted to share some thoughts and suggestions. My aim is to simplify the
logic behind regular screen updates and also attempt to make any on screen timers (elapsed playing time etc) more accurate by
updating them approx on time on exactly one per second boundaries. [to make them look more accurate - especially on SB1]

At present there appear to be two ways of periodically updating the screen: screenSaver and _periodicUpdate. Both of these run
asychonously of anything they display and also run "at most once per second" - i.e. schedule a new timer 1 second from time now to
restart themselves - leading to any delay in a timer firing being added to the next timer, so potentially missing a one per second
update of a display value every now and again.

Neither screenSaver or _periodicUpdate do any update when the screen is animating or scrolling. _periodicUpdate calls update and
hence can't initial scrolling. screenSaver calls scrollBottom and hence initiates scrolling or does a "refresh". On SB2 refresh
does nothing, so additional use of _periodicUpdate has been used for eg the datetime screensaver to ensure redraws - leading to both
running in most cases...

I think this leads to:
1) For SB1/(Slimp3), any display item that updates once per second can be updated by either function and hence can appear to delay
and then jump forwards depending on the interrelation of the timers firing and the value being updated.

2) On SB2, any time displays can be updated up to 1 second after the value actually changes. [Same for SB1, but elapsed time is
less accurate anyway?]

3) Various bits of code and plugins calling update once per second as they can't rely on either of the above. [e.g. signal strength
display]

I would like to suggest the following. Clearly there are things I've not thought about so input and comments on how useful this
would be very welcome, before I do anything on this!

1) Depreciate _peridoicUpdate and drive all periodic updates via screenSaver, so that there is a single once per second timer which
forces periodic screen redraws unless animating.

2) Change scrollBottom back to calling update if no scrolling is required (so that unless animating, update is always called once
per second). [This will cause extra display frames on SB2, but only for the cases when _periodicUpdate is not being used, but see
5) below.]

3) Change screenSaver to scheduling itself 1 second from the last time is was scheduled (i.e. don't accumulate any timer lateness)
by storing a per client time for the next screenSaver.

4) Play some tricks with when screenSaver is scheduled - specifically reset it to update as soon as an STMs frame is received from
SB2 [is this the only time when elaspsed time is reset to 0?] and at 1 second intervals after this. In datetime mode potentially
change this to synchonise with the seconds updating of the clock so that users with ntp synced servers get more accurate clock
displays!

I would also like to make some mods to the graphics rendering code which eases the impact of 2) on SB2:
5) Move the parts cache to be persitent per player, so that each time rendering is called, it is possible to check which of parts
values have changed compared to the previous render for that player. [e.g. most updates in now playing are only for overlay1, so it
seems pointless to re-render everything]

6) On SB2, potentially suppress sending the graphics frame if there are no changes from the last time the screen was drawn
(restoring the refresh functionality)

The outstanding question in my mind is what the right functionality for scrolling is - should the scrolling code cancel itself if
line2 has changed (does not at present, but I did propose a version which did this) or should we rely on each case when line2 could
be updated to kill animations? I think I lean towards the scrolling code doing this as it avoids scrolling being interupted if not
required. [text scrolling should stop after 1 wrap so does not have this problem]

So what do you think?

Adrian

[dean]

Hey Triode,

On Apr 4, 2005, at 2:54 PM, Triode wrote:
> I've been looking at the screen update/display code and wanted to
> share some thoughts and suggestions. My aim is to simplify the logic
> behind regular screen updates and also attempt to make any on screen
> timers (elapsed playing time etc) more accurate by updating them
> approx on time on exactly one per second boundaries. [to make them
> look more accurate - especially on SB1]
Great!

> either screenSaver or _periodicUpdate do any update when the screen is
> animating or scrolling. _periodicUpdate calls update and hence can't
> initial scrolling. screenSaver calls scrollBottom and hence initiates
> scrolling or does a "refresh". On SB2 refresh does nothing, so
> additional use of _periodicUpdate has been used for eg the datetime
> screensaver to ensure redraws - leading to both running in most
> cases...
>
> I think this leads to:
> 1) For SB1/(Slimp3), any display item that updates once per second can
> be updated by either function and hence can appear to delay and then
> jump forwards depending on the interrelation of the timers firing and
> the value being updated.
I'd like to make SB1 work like SB2 and not require periodic updates.
This requires a minor modification to the SB1 firmware, which I'm
testing.
SLIMP3 users will still probably get them, but we can probably relax it
to more like one every 10 seconds (and let the client object take care
of that update, rather than burdening the screenSaver.)

> 2) On SB2, any time displays can be updated up to 1 second after the
> value actually changes.
Great!

> 3) Various bits of code and plugins calling update once per second as
> they can't rely on either of the above. [e.g. signal strength
> display]
Right. Each mode would be responsible for its own updating.

> I would like to suggest the following. Clearly there are things I've
> not thought about so input and comments on how useful this would be
> very welcome, before I do anything on this!
>
> 1) Depreciate _peridoicUpdate and drive all periodic updates via
> screenSaver, so that there is a single once per second timer which
> forces periodic screen redraws unless animating.
Like I said, let's make that a client object responsibility to make
sure that SLIMP3 updates itself.

> 2) Change scrollBottom back to calling update if no scrolling is
> required (so that unless animating, update is always called once per
> second). [This will cause extra display frames on SB2, but only for
> the cases when _periodicUpdate is not being used, but see 5) below.]
In this case, scrollBottom would not do any updating.

> 3) Change screenSaver to scheduling itself 1 second from the last time
> is was scheduled (i.e. don't accumulate any timer lateness) by storing
> a per client time for the next screenSaver.
Sounds reasonable.

> 4) Play some tricks with when screenSaver is scheduled - specifically
> reset it to update as soon as an STMs frame is received from SB2 [is
> this the only time when elaspsed time is reset to 0?] and at 1 second
> intervals after this. In datetime mode potentially change this to
> synchonise with the seconds updating of the clock so that users with
> ntp synced servers get more accurate clock displays!
Right, since the datetime mode would be responsible for updating, it
could do that on second boundaries.

> I would also like to make some mods to the graphics rendering code
> which eases the impact of 2) on SB2:
> 5) Move the parts cache to be persitent per player, so that each time
> rendering is called, it is possible to check which of parts values
> have changed compared to the previous render for that player. [e.g.
> most updates in now playing are only for overlay1, so it seems
> pointless to re-render everything]
Seems very smart, but I imagine that this is a tricky patch. Go for it!

> 6) On SB2, potentially suppress sending the graphics frame if there
> are no changes from the last time the screen was drawn (restoring the
> refresh functionality)
An excellent optimization, but if we aren't sending periodic updates
and are letting the modes trigger the updates, it may be essentially
not necessary.

> The outstanding question in my mind is what the right functionality
> for scrolling is - should the scrolling code cancel itself if line2
> has changed (does not at present, but I did propose a version which
> did this) or should we rely on each case when line2 could be updated
> to kill animations? I think I lean towards the scrolling code doing
> this as it avoids scrolling being interupted if not required. [text
> scrolling should stop after 1 wrap so does not have this problem]
If the bottom line changes, the scrolling should be reset, I believe.