perf(updater): the update chip pulses forever and keeps an idle app at ~30% of a CPU core
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 79/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Domain
- desktop, performance
Research direction
Start with lib/features/updater/update_available_badge.dart and inspect how _pulse.repeat(reverse: true) is controlled, then review the existing badge tests for isPulseAnimating and pulseDuration. Implement a finite initial pulse that leaves the badge in its active colors, and update those tests. The acceptance criteria also call for a cpu_idle_update_badge scenario in benchmark/app_perf_bench.dart; done means the chip still draws attention when it appears and CPU use drops to about 0% once the app is idle.
Written by the indexing model from the issue text.
Description
Problem
While the "vX.Y.Z available" chip is shown (UpdateAvailableBadge, title bar), the app animates it forever with _pulse.repeat(reverse: true) (lib/features/updater/update_available_badge.dart). The animation never stops, so the engine produces a frame at the display rate for as long as the window is open, and an otherwise idle app burns about a third of a CPU core.
This is every user who has a newer release available and has not pressed "Remind me later" (the chip stays until the update is installed or dismissed).
Measurements
Profile build of current dev (0.4.22+5), Linux, 120 Hz display, window 2056x2616. CPU time of all threads of the process from /proc/<pid>/task/*/stat, SQL workspace open, nothing happening:
| State | CPU, % of one core | Frames in 8 s |
|---|---|---|
| no update pending | 0.0-0.1% | 0 |
| update pending, chip pulsing | 29-31% | 475-480 (~59 fps) |
Thread split with the chip: main thread ~1.8-2.0 s of CPU per 8 s (~3.8-4.2 ms per frame), raster ~0.32-0.35 s, GL / compositor threads ~0.1 s.
The same effect showed up when I first measured the real app on 0.4.18, where an update to 0.4.19 existed: 30-38% of a core on the welcome screen with nothing happening, 0.0% after updating.
Wrapping the chip in a RepaintBoundary (tried, reverted) did not help: 29.4% vs 31.4%. The cost is the per-frame pipeline of the whole app (~4 ms main thread per frame), not repainting the chip, so the fix is to produce fewer frames, not to shrink the repaint.
Solution (any of these, ordered by effect)
- Finite pulse. Pulse a few cycles when the chip appears (e.g. 3 x 1.4 s) and then settle to the static "active" colors. After that the app is idle again (0%).
- Pause when the window is not visible. No pulse in the background / minimized (
AppLifecycleState != resumed, orWidgetsBindingObserver), restart on focus. - Optionally re-pulse once per day or on hover, instead of continuously.
Reduced motion already stops it (QueryaMotionLevel.off / disableAnimations); the default Full level should not be a permanent animation either.
Acceptance
- With an update pending and the window idle, CPU drops to ~0% after the initial pulse (measure with the same
/procsampling; add acpu_idle_update_badgescenario tobenchmark/app_perf_bench.dart). - Existing badge tests (
isPulseAnimating,pulseDuration) updated for the finite pulse. - Chip still catches the eye when it first appears.
Related: #987 (120 Hz epic).
- Dominant language
- Dart
- Stars
- 23
- Forks
- 1
- Avg merge
- 45m
- Merged PRs (30d)
- 529
Getting set up
Starts the project's dev container in your browser, under your own GitHub account.
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from QueryaHub/Querya-Desktop
-
bug P3 ux
Difficulty 2/5 1-3 hours Newbie friendliness 79/100
QueryaHub/Querya-Desktop#1837 ·
Maintainers usually reply within 1 day
-
bug mysql P3
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
QueryaHub/Querya-Desktop#1823 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
QueryaHub/Querya-Desktop#1777 ·
Maintainers usually reply within 1 day
-
enhancement ui
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
QueryaHub/Querya-Desktop#1689 ·
Maintainers usually reply within 1 day
-
ui(dialogs): make destructive query and DML preview dialogs adaptive and prevent table name overflowOpenbug frontend
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
QueryaHub/Querya-Desktop#1642 ·
Maintainers usually reply within 1 day
All issues in QueryaHub/Querya-Desktop
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
fossasia/badgemagic-app#2016 ·
Maintainers usually reply within 1 day
-
direct-code
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
aaronified/fluenough#849 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
PATILYASHH/XPENC#179 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
AppFlowy-IO/AppFlowy#9094 ·