feat: add configurable visualizer frame rate setting (30/60/120 FPS)

[devarshbagla]

Summary

Adds a configurable frame rate setting for the Taskbar Visualizer, allowing users to choose between 30, 60, and 120 FPS. Changes apply immediately without requiring a restart.

Motivation

The visualizer's frame rate was previously hardcoded at 30 FPS with no way for users to adjust it. Users with higher refresh rate displays or more powerful hardware may prefer a smoother visualizer experience, while the default remains 30 FPS to keep CPU and battery usage low for everyone else.

Closes #642

Type of Change

• Feature

What Changed

• Added TaskbarVisualizerFrameRate persisted int property to UserSettings.cs with default value of 30, plus a TaskbarVisualizerFrameRateIndex helper for ComboBox binding
• Added OnTaskbarVisualizerFrameRateChanged partial method that notifies the Visualizer immediately on setting change
• Changed _targetFps in Visualizer.cs from a hardcoded readonly field to a mutable static, seeded from settings on startup
• Added UpdateTargetFps() static method in Visualizer.cs for live updates without restart
• Added Frame Rate ComboBox card to TaskbarVisualizerPage.xaml with a battery/CPU warning subtitle, available to all users
• Added 5 localization strings to Dictionary-en-US.xaml

Additional Information

Default remains 30 FPS. The setting is not paywalled.

Checklist

• Code changes are manually tested and working.
• Formatting and naming are consistent with the project.
• Self-review of changes is done.
• AI tools were used (if yes, I reviewed and fully understand the changes myself).

[unchihugo]

Hi @devarshbagla, thank you for the contribution.

Have you ran tests to check whether changing frame rates actually work? From my own observations it seems like it doesn't change much, as data doesn't fill up fast enough for the visualizer beyond 30 FPS.

I'd love to hear your thoughts.

[devarshbagla]

Hi @unchihugo, I dug into the pipeline properly before responding and you're completely right, and I should have caught this before opening the PR.
The actual visual update rate is gated by FFT completions, not the render cap. At 48 kHz with a 4096-sample window, that's ~12 new bar snapshots per second. Since 30 FPS (33ms gate) is already faster than the ~85ms FFT cycle, raising the cap to 60 or 120 FPS produces no additional distinct frames — UpdateBitmap() only ever fires when new FFT data lands, so the extra headroom is never used.
The only edge case where higher FPS would matter is 96kHz+ devices, where FFTs arrive every ~43ms and the 30 FPS gate would occasionally skip one.
If smoother animation were ever a goal, it would require a separate render loop that interpolates _barValues between FFT arrivals.
Happy to close this PR. Thanks for pushing back on it, learned a lot from digging into the pipeline.