perf(updater): the update chip pulses forever and keeps an idle app at ~30% of a CPU core
Maintainer antworten meist innerhalb von 1 Tag
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 3/5
- Geschätzter Aufwand
- 1-2 Tage
- Anfängerfreundlichkeit
- 79/100
- Issue-Typ
- Bug
- Klarheit
- Klar beschrieben
- Aktivitätsstatus
- Aktiv
- Bereich
- desktop, performance
Rechercherichtung
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.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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).
- Vorherrschende Sprache
- Dart
- Sterne
- 23
- Forks
- 1
- Ø Merge
- 31 Min.
- Gemergte PRs (30 T.)
- 570
Entwicklungsumgebung
Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.
- Kein Dockerfile und keine Docker-Compose-Datei
- Hat eine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus QueryaHub/Querya-Desktop
-
enhancement ui
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
QueryaHub/Querya-Desktop#1689 ·
Maintainer antworten meist innerhalb von 1 Tag
-
ui(dialogs): make destructive query and DML preview dialogs adaptive and prevent table name overflowOffenbug frontend
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
QueryaHub/Querya-Desktop#1642 ·
Maintainer antworten meist innerhalb von 1 Tag
-
bug error-handling settings
Schwierigkeit 1/5 1-3 Stunden Anfängerfreundlichkeit 78/100
QueryaHub/Querya-Desktop#1637 ·
Maintainer antworten meist innerhalb von 1 Tag
-
enhancement
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 88/100
QueryaHub/Querya-Desktop#1636 ·
Maintainer antworten meist innerhalb von 1 Tag
-
enhancement marketplace
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
QueryaHub/Querya-Desktop#1635 ·
Maintainer antworten meist innerhalb von 1 Tag
Alle Issues in QueryaHub/Querya-Desktop
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 67/100
PhoebeSoftware/xrooster#41 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 83/100
VeryGoodOpenSource/very_good_templates#665 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
VeryGoodOpenSource/very_good_cli#1783 ·
Maintainer antworten meist innerhalb von 1 Tag
-
bug to check
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 66/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 1/5 1-3 Stunden Anfängerfreundlichkeit 76/100
aaronified/fluenough#665 ·
Maintainer antworten meist innerhalb von 1 Tag