perf(updater): the update chip pulses forever and keeps an idle app at ~30% of a CPU core
Mantenedores costumam responder em até 1 dia
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 3/5
- Tempo estimado
- 1-2 dias
- Facilidade para iniciantes
- 79/100
- Tipo de issue
- Bug
- Clareza
- Claramente especificada
- Status de atividade
- Ativa
- Domínio
- desktop, performance
Direção de pesquisa
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.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
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).
- Linguagem predominante
- Dart
- Estrelas
- 23
- Forks
- 1
- Merge médio
- 31min
- PRs com merge (30d)
- 570
Preparar o ambiente
Inicia o contêiner de desenvolvimento do projeto no navegador, com a sua própria conta do GitHub.
- Sem Dockerfile nem arquivo Docker Compose
- Tem um modelo de pull request
- Ler o guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de QueryaHub/Querya-Desktop
-
enhancement ui
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
QueryaHub/Querya-Desktop#1689 ·
Mantenedores costumam responder em até 1 dia
-
ui(dialogs): make destructive query and DML preview dialogs adaptive and prevent table name overflowAbertabug frontend
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 82/100
QueryaHub/Querya-Desktop#1642 ·
Mantenedores costumam responder em até 1 dia
-
bug error-handling settings
Dificuldade 1/5 1-3 horas Facilidade para iniciantes 78/100
QueryaHub/Querya-Desktop#1637 ·
Mantenedores costumam responder em até 1 dia
-
enhancement
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 88/100
QueryaHub/Querya-Desktop#1636 ·
Mantenedores costumam responder em até 1 dia
-
enhancement marketplace
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
QueryaHub/Querya-Desktop#1635 ·
Mantenedores costumam responder em até 1 dia
Todas as issues de QueryaHub/Querya-Desktop
Issues semelhantes
-
agent:in-progress agent:ready feature P2 · 中 区域: 悬浮窗
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 85/100
ASDW51/DanmuFloat#178 ·
Mantenedores costumam responder em até 1 dia
-
Missing workoutsAbertaenhancement
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 67/100
InlitX/GymMane#237 · 1 comentário ·
Mantenedores costumam responder em até 5 dias
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 66/100
AppFlowy-IO/AppFlowy#9077 ·
-
bug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 68/100
Abhinivesh2729/Thinai#41 · 1 comentário ·
Mantenedores costumam responder em até 1 dia
-
enhancement
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 64/100
0niel/university-app#617 ·
Mantenedores costumam responder em até 1 dia