Gameplay tests: bound the rendering duty cycle, not just the interval - #8937
Merged
Conversation
When a single render costs more than the render interval (a 3D scene on software WebGL takes ~350ms), an interval cap skips nothing: the next render is due the instant the previous one ends. Measure the cost of each render (the whole animation frame tick) and wait for 4x that cost before the next one, capping rendering at ~20% of the wall clock whatever a render costs. Measured on CI-like machines: 3D runs were still spending 99% of their time rendering with the interval cap alone. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AaQQdPZ68X8zkybtsxWE1b
4ian
force-pushed
the
claude/gameplay-tests-render-duty-cycle
branch
from
August 9, 2026 13:41
2c9ef64 to
886782f
Compare
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
2 participants
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.
Follow-up to the 250ms render cap (
4cc37b4), from CI measurements: 2D runs got 2-3× faster, but 3D barely moved (1.2-1.3×) — a single 3D render on software WebGL costs ~350ms, more than the interval itself, sonow - lastRender >= 250is true again the instant a render finishes and nothing is ever skipped.Fast runs now measure the cost of each render (the whole animation frame tick, via a
setTimeout(0)sandwich so the game's render callback is included) and wait for 4× that cost before the next one — capping rendering at ~20% of the wall clock whatever a render costs. Cheap renders keep the previous behavior (the 250ms interval stays the floor); the screenshot-forced render feeds the same measurement.On the reported 3D numbers (4.25ms step, 371ms/frame wall clock) this should bring frames from ~371ms to the ~5-20ms range once amortized. Paced runs remain untouched.
Validated: GDJS type-check and build clean, harness karma suite 32/32.
🤖 Generated with Claude Code
https://claude.ai/code/session_01AaQQdPZ68X8zkybtsxWE1b