fix(razer): smooth wrapper colours between Chroma service updates - #296
Open
moeilijk wants to merge 1 commit into
Open
fix(razer): smooth wrapper colours between Chroma service updates#296moeilijk wants to merge 1 commit into
moeilijk wants to merge 1 commit into
Conversation
RzSDKService writes the emulator buffers at ~10 Hz with multi-frame gaps, so raw wrapper output steps visibly on the keyboard. Each key now eases toward the newest service colour per render tick (tau 100 ms, new per-layer SmoothingEnabled property, default on), turning steps into fades. This requires rendering every tick, so the IsStale/_updatedLayers short-circuit is removed — it was also a plain HashSet cleared from the reader thread while the render thread Add'ed, which corrupted the set (InvalidOperationException in Render). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
List any issues that this PR fixes: none
This pull request proposes the following changes:
SmoothingEnabledproperty, default on, logic-overridable)RzHelper.IsStale/_updatedLayersshort-circuit: it was a plainHashSetcleared from the reader thread while the render threadAdded, which corrupts the set (observed in the wild:InvalidOperationException: Operations that change non-concurrent collections must have exclusive accessthrown fromRazerLayerHandler.Render); smoothing needs per-tick rendering anywayWhy: measured on a live system (RazerSdkReader with no work in the hot path),
RzSDKServicerepublishes the emulator keyboard buffer at most ~10 Hz (inter-update intervals cluster at ~100 ms) with occasional 200-600 ms gaps followed by colour jumps. Mirrored raw, a classic Chroma game whose effect ramps colours (e.g. BG3's breathing menu) looks visibly stepped on the keyboard.This ~10 Hz is not the reader being slow: Razer's own Chroma SDK FAQ states that "reducing the delay down below 100ms starts to really get out of sync and the keyboard seems to lose steady timing", while animation content is authored at 30 FPS (verified: the 007 catalog keyboard
.chromaframes are a uniform 33 ms). So the pipeline delivers ~30 FPS content over a link that only reliably services ~10 Hz, and the documented pipeline has no interpolation step to bridge the two. This layer adds that step client-side: easing toward the latest buffer value each render tick reconstructs the intended motion instead of showing the raw ~10 Hz samples. It is opt-out viaSmoothingEnabled.Known issues/To do: