Quick answer
A frame-time graph shows how long each frame took, so it reveals delivery problems that an average FPS value hides. Read the vertical spikes, the stable baseline and the timing budget together. A 60 FPS target allows 16.7 milliseconds per frame, while 144 FPS allows only 6.9 milliseconds.
No online score observes your clocks, temperatures, software version, memory pressure or exact scene. Confirm the suspected stage with a repeatable capture before changing hardware.
What can cause this performance pattern?
A useful diagnosis begins with several competing explanations. The following causes can produce similar headline utilization while requiring different fixes.
Signals worth recording
- A one-off asset load can create an isolated spike.
- A repeating sawtooth can indicate pacing or synchronization behavior.
- A rising baseline can follow heat, power or scene complexity.
- Regular flat steps can be caused by a frame cap.
Record the event in the workload where it matters. A lightweight menu, loading screen or empty benchmark scene cannot represent the busiest part of a game or application.
Run a controlled test
Keep the application, scene, software version and warm-up state fixed. Change one input, record the response and restore the baseline before the next test.
Step-by-step test plan
- Capture the same sixty-second route three times.
- Remove menus and loading screens from the sample.
- Mark the target frame-time line before comparing runs.
- Match each spike with clocks, utilization and memory activity.
Repeat the capture at least three times when results vary. The measured change should be larger than normal run-to-run movement before it is used as buying evidence.
How to interpret the evidence
Observation, test and meaning
| Observation | Controlled change | Likely interpretation |
|---|---|---|
| Single isolated spike | Repeat after warm-up | Compilation or asset loading is more likely |
| Sustained high baseline | Lower rendering load | A clear response supports GPU pressure |
| Flat ceiling | Check caps and V-Sync | The limiter may be intentional |
The interpretation is directional. More than one limit can appear in a single workload, and the slowest stage can move after a setting, cap or hardware change.
Turn the result into a useful decision
Choose the next test from the shape of the trace. Repeating high frame time needs a throughput test; isolated spikes need an event correlation. Save the raw capture so a driver, setting or hardware change can be compared against exactly the same route.
Article-specific measurement worksheet
Label these fields in the capture notes so another run can reproduce the same question:
- capture duration
- millisecond axis
- spike timestamp
- baseline band
- target budget
- warm pass
- present interval
- event marker
Common mistakes to avoid
- Treating one spike as a permanent bottleneck.
- Comparing traces from different scenes.
- Reading FPS and milliseconds as interchangeable.
Short summary: define the target, capture the exact problem, change one variable and buy only when the expected stage responds consistently.
