fix(ui): pace repaint work and bound runtime workers#1372
Open
maybeknott wants to merge 3 commits into
Open
Conversation
The desktop UI scheduled a repaint every 500 ms and sent stats-poll commands on the same update cadence regardless of whether the proxy was running, a transient message was visible, or any background operation was in flight. That kept the immediate-mode interface waking regularly even when the app was stopped and the window contained only static state. Add a small activity predicate over UI state and use it to select the repaint cadence. Running proxy sessions, proxy startup/shutdown windows, certificate operations, downloads, update checks, SNI probes, and fresh transient status lines keep the existing 500 ms cadence. Fully idle UI state falls back to a slower two-second repaint request while still allowing egui to repaint immediately for user input. Gate stats polling on the same active-state predicate so stopped or fully idle windows do not enqueue redundant PollStats commands into the background thread. The visible text, controls, command handlers, proxy lifecycle, and persisted configuration remain unchanged. Add focused unit tests for the activity predicate covering idle state, running proxy state, in-flight SNI probes, and expired transient status timestamps.
maybeknott
changed the title
Replace the desktop UI background runtime's implicit Tokio defaults with an explicit multi-thread runtime builder. The UI now sizes its async worker pool from available_parallelism(), clamps long-lived worker threads to a small 2..=4 range, names worker threads as mhrv-ui-worker, and bounds the blocking pool separately at 32 threads. This keeps proxy lifecycle tasks, stats polling, certificate operations, tests, scans, and update/download work on the same command paths while making the scheduler shape predictable on both low-core machines and high-core desktops. Small devices avoid a single-worker UI runtime, and large desktops avoid creating an oversized worker pool for a UI-owned background coordinator. Log the selected runtime shape at UI startup so support reports can distinguish runtime sizing from proxy transport behavior. Add focused unit coverage for the worker-count policy across low-core, midrange, and high-core inputs.
Rename the desktop runtime sizing tests into their own module so they do not collide with the repaint pacing tests in the same binary test namespace. This keeps the repaint activity checks and runtime worker-count checks independently addressable while allowing the UI test binary to compile with the ui feature enabled.
maybeknott
changed the title
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
1 participant
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.
This reduces idle desktop UI work and bounds the background runtime used by the desktop control surface.
The UI now derives repaint cadence from visible activity instead of requesting continuous redraws. Running proxy sessions, proxy start/stop transitions, certificate operations, active download/update/test/SNI probe states, and fresh transient messages keep the window on an active repaint interval. Idle windows use a slower interval so unchanged controls do not continuously consume CPU/GPU time.
Stats polling follows the same activity model. Active UI states continue to receive frequent snapshots, while idle states avoid unnecessary background polling. The transient status/message lifetimes are named constants shared by the activity detector and rendering path so repaint decisions and visible message expiry stay aligned.
The desktop background runtime is built with an explicit multi-thread Tokio runtime. Worker allocation is hardware-aware and clamped to a small bounded range, with blocking threads capped separately. Startup logs include the selected worker count so runtime sizing can be diagnosed without instrumenting the scheduler.
Validation:
git diff --check upstream/main..HEADcargo test repaint --features ui --bin mhrv-rs-uicargo test desktop_runtime_worker_count --features ui --bin mhrv-rs-ui