Consolidate Widget draw and update frequency management #295

New issue

Closed

opened 2025-03-16 14:23:25 +00:00 by dreed47 · 1 comment

dreed47 commented

2025-03-16 14:23:25 +00:00

(Migrated from github.com)

Consolidates complex time update frequency code in one place.
Dramatically reduce calls to widget draw() and update()
Widgets don’t need to manage the update frequency logic, just set the desired update() and draw() frequency in their constructors.
WidgetSet::drawCurrent() and WidgetSet::updateCurrent() can check to see if the active widget set their draw and update timers. If they did, then check to see if they are ready to be called. If they didn’t set their timers, then call the draw() and update() methods as normal, assuming the widgets will manage their own timers (as it is today). This will allow a gradual rollout of this centralized widget timer management.
Makes draw() and update() methods simpler as you know if they are called that they perform their functions instead of trying to decide if it’s okay to perform their functions.

Example widget code:

m_drawTimer(addDrawRefreshFrequency(TimeFrequency::OneSecond));   // Draw every 1 second
m_updateTimer(addUpdateRefreshFrequency(TimeFrequency::TenMinutes));   // Update every 10 minutes

And your timers can be reset if needed:

resetTimer(m_drawTimer);

Also we could specify timers values like this

#ifndef WEATHER_UPDATE_DELAY
    #define WEATHER_UPDATE_DELAY TimeFrequency::TenMinutes
#endif

Which would allow people to override the defaults in the config if they wanted.

We could implement this today and use for just one widget to try it out and if it seems beneficial roll it to all the widgets.

PR #297

We have a lot of very similar code across the widgets for managing timers for knowing when to update data and draw screens. One effect of this is that the active widget gets its draw() and update() methods called every time thru the main loop and sometimes this is the desired effect but most of the time they do nothing (or nothing meaningful) and return. This code could be extrapolated out into the Widget.cpp. And WidgetSet can use these widget-based timers to know when it needs to call the draw() and update() methods. This has several benefits: 1. Consolidates complex time update frequency code in one place. 2. Dramatically reduce calls to widget draw() and update() 3. Widgets don’t need to manage the update frequency logic, just set the desired update() and draw() frequency in their constructors. 4. WidgetSet::drawCurrent() and WidgetSet::updateCurrent() can check to see if the active widget set their draw and update timers. If they did, then check to see if they are ready to be called. If they didn’t set their timers, then call the draw() and update() methods as normal, assuming the widgets will manage their own timers (as it is today). This will allow a gradual rollout of this centralized widget timer management. 5. Makes draw() and update() methods simpler as you know if they are called that they perform their functions instead of trying to decide if it’s okay to perform their functions. Example widget code: ```c++ m_drawTimer(addDrawRefreshFrequency(TimeFrequency::OneSecond)); // Draw every 1 second m_updateTimer(addUpdateRefreshFrequency(TimeFrequency::TenMinutes)); // Update every 10 minutes ``` And your timers can be reset if needed: ```c++ resetTimer(m_drawTimer); ``` Also we could specify timers values like this ```c++ #ifndef WEATHER_UPDATE_DELAY #define WEATHER_UPDATE_DELAY TimeFrequency::TenMinutes #endif ``` Which would allow people to override the defaults in the config if they wanted. We could implement this today and use for just one widget to try it out and if it seems beneficial roll it to all the widgets. PR #297

dreed47 commented

2025-03-17 02:33:18 +00:00

(Migrated from github.com)

changes merged