Skip to content

Drive water ring and bar preview animations from FrameAnimation - #91

Open
hugorolimf wants to merge 1 commit into
HANCORE-linux:mainfrom
hugorolimf:fix/frame-synced-animations
Open

hugorolimf wants to merge 1 commit into
HANCORE-linux:mainfrom
hugorolimf:fix/frame-synced-animations

Conversation

@hugorolimf

Copy link
Copy Markdown

Problem

On a 144 Hz display (Omarchy 4.0.6, Quickshell, Hyprland 0.56.2) some Shibumi animations look like they run at 20-30 Hz. An isolated Quickshell PanelWindow with a FrameAnimation counter measured 144 fps on both outputs, so the limit is in the Shibumi code, not the host:

  • shared/presentation/WaterRing.qml (CPU, battery and temperature panels) redraws from a 50 ms Timer, i.e. 20 fps.
  • hancore.shibumi.control-center/ActiveBarSettingsPage.qml repaints the gap-animation preview from a 33 ms Timer, i.e. 30 fps.

Change

Both timers are replaced by FrameAnimation, so they follow the display refresh rate.

  • The water-ring wave keeps its previous speed (20 steps/s) and the percent easing keeps its 25% per 50 ms rate. Both are scaled by the real frame time, clamped to 100 ms so a stalled frame cannot jump the phase.
  • waveFrame is now a real (also in BatteryRing.qml) so the phase advances smoothly instead of in 1/72 steps.
  • The preview paint already derives its phase from Date.now(), so only the repaint trigger changes.
  • Canonical WaterRing.qml is changed and the three vendored copies are synchronized with scripts/sync-shared.sh --write.

Not changed: the 60 fps Cava input of the media spectrum, which is bounded by the audio source rather than a timer.

Affected plugins

hancore.shibumi.cpu, hancore.shibumi.battery, hancore.shibumi.temperature, hancore.shibumi.control-center.

Checks run

  • git diff --check
  • ./scripts/sync-shared.sh --check
  • tests/power-plugins-regression.sh
  • tests/control-center-regression.sh

The full tests/contract-regression.sh was not run.

Live UI evidence

Not captured. The change was not rendered on a live Wayland session, so the visual result at 144 Hz and the extra CPU cost of redrawing the Canvas at that rate are unverified. To verify: open the CPU, battery or temperature panel with water enabled, and open Bars -> Gap Animations in the control center, on a high-refresh output. Multi-output was not tested.

🤖 Generated with Claude Code

The CPU, battery and temperature water rings redrew from a 50 ms Timer
(20 fps) and the bar gap-animation preview from a 33 ms Timer (30 fps),
so they looked choppy on high-refresh displays. Use FrameAnimation so
they follow the display refresh rate.

The wave keeps its 20 steps/s speed and the percent easing keeps its
25% per 50 ms rate, both scaled by the real frame time (clamped to
100 ms), so the visuals match the previous timing on any refresh rate.
waveFrame becomes a real so the phase advances smoothly.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant