Fan-made · Desktop-only · Not affiliated with any car maker
0. The hitch is real. The diagnosis is still open.
You enter the garage. The game catches for a moment. You open the script, spot a loop, and start rewriting it.
That is an understandable reaction. It is also a diagnosis made before collecting evidence.
For a desktop-browser project like CGT Rocket X Racer, the useful question is narrower: what was the browser doing when the frame stalled? If the hitch coincides with a texture's first use, another GDScript pass may target the wrong work.
This is a verification workflow for Godot Compatibility builds in desktop Chrome. It starts with a short Performance recording and ends with a decision about where to investigate next.
1. Why “the script is busy” is not enough
A script hotspot tells you where script execution costs time. It does not automatically explain a particular missed frame in the browser.
Godot's documented web path uses Compatibility and WebGL 2.0. That makes browser-side rendering work part of the investigation, alongside gameplay execution. See the Godot web export documentation.
A texture can be downloaded and loaded without all the work associated with its first visible use having finished. Resource preparation, transfer to graphics memory, and rendering can make that first encounter different from later ones. A large texture or atlas is therefore a suspect, not a verdict.
With a single-threaded build, gameplay and rendering-related CPU work can also compete on the same thread. A long block around an engine frame is not necessarily expensive gameplay logic.
Keep three possibilities separate: recurring script work, first-use resource work, and browser presentation work. The trace should help distinguish them before any rewrite begins.
2. Record one transition, then repeat it
Choose a reproducible action: entering the garage for the first time, or showing a previously unseen level skin. Avoid recording a whole play session and hunting through unrelated activity.
Establish the capture conditions
Write down the build, Chrome version, desktop hardware, window size, and whether the page was freshly loaded. Keep throttling settings unchanged between captures. A fresh page is not necessarily an empty browser cache; describe what you actually reset.
Open DevTools, select Performance, and start recording before the action. Perform it once, wait until the scene settles, then stop. Enable screenshots if they help identify when the scene changes, while remembering that recording itself adds overhead.
Chrome's Performance reference describes the Main flame chart, GPU activity section, and inspection views used here.
Locate the hitch before naming it
Find the transition using the captured frames and screenshots where available. Select a narrow interval around the stall. Inspect the Main track, then compare the timing with GPU activity if your recording exposes it.
Select the expensive events and inspect their details and call stacks. Use Call tree for the calling path and Bottom-up to see which recorded activities account for time within that interval.
Do not treat the widest rectangle as a diagnosis. Ask what work it represents and whether it overlaps the visible hitch.
Recognize a family of work, not a magic label
Look for evidence of image preparation, texture transfer, or graphics work clustered around the resource's first appearance. Depending on the build and capture, relevant clues might include image decoding, bitmap preparation, or WebGL texture API calls visible in a stack.
texImage2D and texSubImage2D are API names to recognize if exposed, not guaranteed Performance event labels. Likewise, an ImageBitmap reference alone would not prove a GPU upload. Godot resources do not all travel through the same browser image path.
Chrome versions, platforms, symbols, and capture settings change what is visible. A generic WebAssembly block or GPU activity band does not identify a texture by itself. Upload submission and GPU execution can also occur at different times.
Compare the second encounter
Without reloading the page, leave and repeat the same transition. Keep the camera, visible content, and interaction sequence comparable. Check that the resource stayed resident; unloading it would change the experiment.
If the first encounter hitches and the second does not, that supports a first-use explanation. It does not isolate upload from decoding, shader compilation, scene initialization, or other one-time work.
Strengthen the case with a controlled development build: keep gameplay logic and scene structure constant, but substitute a smaller test texture. Repeat the captures. If the relevant activity and hitch consistently change together, the upload hypothesis becomes stronger. This is a diagnostic experiment, not a shipping prescription.
Godot profiler data can help identify script or physics activity during the same action. Use it as corroboration; the browser recording remains the evidence for the browser-visible stall.
3. Let the evidence choose the next investigation
| Evidence around the hitch | Next step |
|---|---|
| First-use spike, identifiable texture-related activity, and a controlled resource test that changes the stall | Investigate resource preparation, texture dimensions, and when resources become visible or resident. |
| Repeated script or physics work aligned with repeated stalls | Identify the responsible function or subsystem before changing GDScript. |
| Layout or compositing work aligned with the transition | Inspect the page wrapper, fullscreen changes, and canvas sizing. |
| Opaque engine activity with no useful attribution | Improve the capture or isolate variables; keep the cause unresolved. |
These are investigation routes, not mutually exclusive causes. A scene transition can trigger several kinds of work together.
Resource changes come after evidence. Import decisions and atlas sizing may deserve attention then, but this article does not prescribe a compression or export-settings recipe. The immediate deliverable is a defensible diagnosis.
4. Be precise about what you proved
“Only the first visit stutters” is an observation. “First-use work is implicated” is an inference. “Texture upload causes this hitch” needs stronger attribution and a repeatable comparison.
Save the recordings with their capture conditions. Note what changed between tests and what stayed constant. If your trace cannot separate upload from other graphics initialization, report that limitation instead of promoting a guess into a finding.
No particular time saving follows from this workflow. It helps choose the next experiment. These checks also concern desktop Chrome; they establish no mobile-browser performance claim.
5. Evidence before the rewrite
Before changing GDScript, capture the hitch, compare first and repeat encounters, and test the most plausible explanation. Rewrite when the evidence points to script work.
For your last web hitch, did you open Performance first, or change the script first?
Desktop build: https://cgt.monster/x/devto8
Top comments (0)