fix: move timestamp fetch to background thread to prevent UI freeze#63
Merged
matheus-git merged 1 commit intomatheus-git:mainfrom Feb 16, 2026
Merged
fix: move timestamp fetch to background thread to prevent UI freeze#63matheus-git merged 1 commit intomatheus-git:mainfrom
matheus-git merged 1 commit intomatheus-git:mainfrom
Conversation
The runtime timestamp feature was fetching ActiveEnterTimestamp via two synchronous D-Bus calls (LoadUnit + Get) directly inside the render loop. This blocked the main thread, causing a noticeable freeze on startup before the TUI appeared, and on every selection change while scrolling. How each concern is addressed: 1. TUI freezes before rendering: refresh_selected_timestamp() no longer blocks on D-Bus. It sends the service name to a channel and returns immediately, allowing the first render to complete without delay. The timestamp appears asynchronously once the worker delivers the result via UpdateTimestamp. 2. Timestamp fetch moved to a dedicated worker thread: spawn_timestamp_worker() creates a long-lived background thread that receives requests through an mpsc channel, fetches timestamps from the repository, and sends results back through the existing AppEvent channel. 3. Rapid scrolling no longer floods D-Bus with requests: The worker drains all queued requests before fetching, keeping only the latest one. If the user scrolls past 30 services while a fetch is in-flight, only the last service's timestamp is actually fetched. Additionally, update_timestamp() verifies the result still matches the currently selected service before applying it, discarding stale responses. Signed-off-by: Reid Tonking <Reid.Tonking@gmail.com>
Owner
|
It worked, thank you. It really is an issue that I only noticed when I installed it on my VPS, and since the goal of the project is to have good performance (to run smoothly even on low-end computers), I asked you to make that update. |
Contributor
Author
|
@matheus-git understandable and glad it worked. I need to fire up my old Raspberry Pi 3/4 as a test platform maybe |
Owner
|
Cool, let me know if you test it. |
Contributor
Author
|
Tested on a raspberry pi 2w. I don't think it's capable of building it from source (could be that building plus ssh caused some issues or just RAM constraints), but it can run it (cross compiled on desktop and scp'd). Small hitch on start up, but i'd wager that's less of a code issue and more of a hardware capability concern. Runs pretty smooth once started up. Screen.Recording.2026-02-16.at.16.16.39.mov |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The runtime timestamp feature was fetching ActiveEnterTimestamp via two synchronous D-Bus calls (LoadUnit + Get) directly inside the render loop. This blocked the main thread, causing a noticeable freeze on startup before the TUI appeared, and on every selection change while scrolling.
How each concern is addressed:
TUI freezes before rendering: refresh_selected_timestamp() no longer blocks on D-Bus. It sends the service name to a channel and returns immediately, allowing the first render to complete without delay. The timestamp appears asynchronously once the worker delivers the result via UpdateTimestamp.
Timestamp fetch moved to a dedicated worker thread: spawn_timestamp_worker() creates a long-lived background thread that receives requests through an mpsc channel, fetches timestamps from the repository, and sends results back through the existing AppEvent channel.
Rapid scrolling no longer floods D-Bus with requests: The worker drains all queued requests before fetching, keeping only the latest one. If the user scrolls past 30 services while a fetch is in-flight, only the last service's timestamp is actually fetched. Additionally, update_timestamp() verifies the result still matches the currently selected service before applying it, discarding stale responses.