[GH-ISSUE #141] [ENHANCEMENT] 🧩 Improve playback speed UX consistency and decouple input handling #35

New issue

Open

opened 2026-05-07 00:18:02 +02:00 by BreizhHardware · 0 comments

BreizhHardware commented

2026-05-07 00:18:02 +02:00

Owner

Originally created by @anirudhk06 on GitHub (Dec 28, 2025).
Original GitHub issue: https://github.com/IAmTomShaw/f1-race-replay/issues/141

The playback speed bug was recently fixed (thank you for that!).

While reviewing the current implementation, I noticed two follow-up
improvement opportunities that could enhance usability and maintainability:

UX consistency
Playback speed currently scales multiplicatively. This means the resulting
values depend on the previous history (e.g. starting from 0.1 results in
0.2 → 0.4 → 0.8, while starting from 1.0 results in 2 → 4 → 8).
This can feel unintuitive for users and produces non-standard speeds
such as 1.6x or 3.2x.

A step-based (0.5) approach (e.g. 0.1 → 0.5 → 1 → 1.5 → 2 . . . 4x) would provide more
predictable and user-friendly behavior.
Maintainability
The input handling logic is currently implemented using tightly coupled
conditional branches inside the window class. This makes future changes
(keyboard/mouse/UI controls) harder to maintain and extend.

Would you be open to a small refactor that:

Uses explicit playback speed steps for consistent UX
Reduces conditional branching by extracting playback speed logic
Preserves existing behavior and avoids functional regressions

I’m happy to prepare a minimal PR if this sounds reasonable.

Originally created by @anirudhk06 on GitHub (Dec 28, 2025). Original GitHub issue: https://github.com/IAmTomShaw/f1-race-replay/issues/141 The playback speed bug was recently fixed (thank you for that!). While reviewing the current implementation, I noticed two follow-up improvement opportunities that could enhance usability and maintainability: 1. UX consistency Playback speed currently scales multiplicatively. This means the resulting values depend on the previous history (e.g. starting from 0.1 results in 0.2 → 0.4 → 0.8, while starting from 1.0 results in 2 → 4 → 8). This can feel unintuitive for users and produces non-standard speeds such as 1.6x or 3.2x. A step-based (0.5) approach (e.g. 0.1 → 0.5 → 1 → 1.5 → 2 . . . 4x) would provide more predictable and user-friendly behavior. 2. Maintainability The input handling logic is currently implemented using tightly coupled conditional branches inside the window class. This makes future changes (keyboard/mouse/UI controls) harder to maintain and extend. Would you be open to a small refactor that: - Uses explicit playback speed steps for consistent UX - Reduces conditional branching by extracting playback speed logic - Preserves existing behavior and avoids functional regressions I’m happy to prepare a minimal PR if this sounds reasonable.