Repository navigation
Conversation
The main loop polls at a fixed TARGET_FPS (20Hz) forever via SDL_PollEvent + a fixed-rate delay, even when the app is fully idle on a static page with nothing held or animating. Rendering is already change-driven, but the wake cadence was not, so the CPU (and battery) paid for 20 wakeups a second regardless of whether anything was happening. Adds View::on_tick()/wants_continuous_render() (a view opts in to mean "keep ticking at full rate even with no input", for a future animated view such as auto-scroll - unused by any current view, so no behavior change yet) and HeldKeyTracker::any_held(). When nothing is held and the active view does not need continuous rendering, the loop blocks on the next real input event instead of polling, using a small local poll_event_with_timeout() rather than SDL_WaitEventTimeout itself, since that symbol is not declared in this toolchain's SDL1.2 headers. No behavior change while input is active or a view opts into continuous rendering; the only difference is fewer wakeups while a book just sits on screen. Verified this still compiles and links against the real Miyoo Mini cross-compile toolchain. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
So I think the loop as-is wakes up 20x per second but does almost no work. The replacement in this PR will wake it up 100x per second and do a similar amount of work per wake. I understand SDL2 has more options to wait for events. |
|
I'm not sure about that, as I feel that it consumes less than before (but as I'm still human, I'm prone to judgment error). You're right mentioning that it wakes 100x/s, but the amount of work is very less (according to Claude judgement). I will modify this value back to 50ms, and keep the rest untouched, so that we wake as frequently as before but do less work. In fact, originally I had the feeling that this app was consuming quite a lot of power just to keep a screen displayed and changing the content from time to time, so I initiated this research of losses. The first comment of Claude was that it was already quite optimized, and this loop was basically the only place where it found some possible payout. |
2 participants
The main loop polls at a fixed TARGET_FPS (20Hz) forever via SDL_PollEvent + a fixed-rate delay, even when the app is fully idle on a static page with nothing held or animating. Rendering is already change-driven, but the wake cadence was not, so the CPU (and battery) paid for 20 wakeups a second regardless of whether anything was happening.
Adds View::on_tick()/wants_continuous_render() (a view opts in to mean "keep ticking at full rate even with no input", for a future animated view such as auto-scroll - unused by any current view, so no behavior change yet) and HeldKeyTracker::any_held(). When nothing is held and the active view does not need continuous rendering, the loop blocks on the next real input event instead of polling, using a small local poll_event_with_timeout() rather than SDL_WaitEventTimeout itself, since that symbol is not declared in this toolchain's SDL1.2 headers.
No behavior change while input is active or a view opts into continuous rendering; the only difference is fewer wakeups while a book just sits on screen. Verified this still compiles and links against the real Miyoo Mini cross-compile toolchain.