The counter says 180 FPS. You turn the camera, the game catches for half a beat, then the counter calmly returns to 180 as if nothing happened. Lowering every graphics option gives you 240 FPS and the same catch. Reinstalling the driver changes nothing.
The contradiction disappears when you stop asking how many frames arrived in a second and ask how long each individual frame took. At 60 FPS, the frame budget is 16.67 ms. At 144 FPS it is 6.94 ms. Ninety-nine frames can meet that budget, while one frame takes 70 ms. The average still looks excellent. Your eyes feel the 70 ms pause.
That pause has a shape. A hitch the first time an effect appears is not the same problem as a hitch every time you cross a map boundary. A regular pulse is not the same problem as a slow decline after twenty minutes. This guide uses those fingerprints to narrow the cause before you start changing settings.
FPS, frame time and 1% lows are three different answers
FPS is throughput. Frame time is latency. The two are related by 1000 / FPS, but an
average destroys timing information. It cannot tell you whether 120 frames arrived evenly every
8.33 ms or in uneven clumps.
| Target | Time available for one frame | What a 50 ms frame feels like |
|---|---|---|
| 60 FPS | 16.67 ms | About three frame budgets in one |
| 120 FPS | 8.33 ms | About six frame budgets in one |
| 144 FPS | 6.94 ms | About seven frame budgets in one |
| 240 FPS | 4.17 ms | About twelve frame budgets in one |
A 1% low is useful because it summarizes the slowest group of frames instead of the whole run. Different tools calculate the displayed number slightly differently, so do not treat it as a universal laboratory unit. It answers one useful question: is the bad feeling visible in the capture? It does not answer why.
What the stutter pattern tells you
| When it happens | Most useful first suspect | Test that separates it |
|---|---|---|
| Only the first time you see a spell, material or new area | Shader or pipeline compilation | Repeat the exact action. If the second pass is clean until caches are cleared or the driver changes, compilation moves up the list. |
| While turning quickly or crossing the same map boundary | Asset streaming, storage or VRAM pressure | Repeat the route. Lower texture quality only. If the spike shrinks, investigate the texture pool and video-memory budget. |
| GPU sits near its limit and pacing is rough everywhere | GPU saturation and frame queue | Apply a sensible FPS cap below the sustainable rate. A flatter graph points to headroom, not a mysterious Windows tweak. |
| GPU usage drops during the hitch while one CPU thread is full | CPU or game-thread bottleneck | Show logical processors, reduce CPU-heavy settings such as crowd density or view distance, then repeat the same scene. |
| Every few seconds, even while standing still | Overlay, capture tool, monitoring poll, driver or background task | Disable nonessential overlays and capture tools one at a time. A regular fault deserves a regular suspect. |
| Only after the machine has been hot for a while | Thermal or power limit, memory growth | Log temperatures, clocks, power and memory from launch until the first bad interval. |
| Only in online play | Network or server simulation, not rendering | Separate a visual frame hitch from rubber-banding. Record an offline or training scene before touching graphics settings. |
Shader compilation stutter
Modern games combine shaders and render states into pipeline state objects. If a required combination was not prepared before play, the game may have to wait while the driver compiles it. Epic describes the same failure mode in its Unreal Engine work: when a needed PSO is still being compiled, the game can hitch as it is requested. The important clue is novelty. A new effect hurts, its immediate repeat often does not.
You cannot repair missing game-side precaching with a registry file. Let a legitimate compilation screen finish, avoid repeatedly deleting shader caches, and check whether the developer has shipped a fix. A driver update can invalidate a cache, so a short first-run regression after an update is not proof that the driver is permanently bad.
Asset streaming and VRAM pressure
Games do not keep every full-resolution texture and mesh resident at once. They stream what the scene needs. Unreal Engine's own documentation describes a texture pool with a budget and mip levels loaded or dropped to stay within it. When a route through the world repeatedly triggers loading, the spike can come from storage, decompression, CPU work, transfer to the GPU, or eviction because the current video-memory budget is tight.
This is why lowering shadows may do nothing while lowering textures helps. It is also why "the game allocated all my VRAM" is not enough evidence by itself. Allocation, active use and budget pressure are not identical. The separate VRAM guide shows how to read them without guessing.
CPU-bound does not mean 100% total CPU
A game can wait on one critical thread while the other logical processors have room. Total CPU then looks harmless. During that wait the GPU may fall idle because the CPU has not produced the next work in time. Microsoft's DirectX explanation is simple: a CPU-bound game leaves the GPU waiting, while a GPU-bound game keeps the GPU as the limiting stage.
Lowering resolution mainly reduces GPU work. If the hitch is on the game thread, the result may be higher average FPS with the same spikes. That is not a failed test. It is evidence.
A ten-minute test that produces useful evidence
- Choose a repeatable scene. A save point, a training map or a 30-second route. Random multiplayer is a poor benchmark because the workload changes underneath you.
- Warm up once. Run the route, then capture the second run. If only the first run is bad, capture both and label them. That difference is evidence for compilation or caching.
- Record per-frame data. PresentMon is the open-source base used by several capture tools and can record CPU, GPU and display frame durations. A live FPS counter alone is not enough.
- Record system context at the same time. GPU load and memory, per-core CPU, system RAM, disk activity, temperatures, clocks and power. The spike matters only when you can line it up with what the rest of the machine did.
- Change one variable. Texture quality for a streaming suspicion. An FPS cap for GPU saturation. One overlay for a periodic hitch. Repeat the same route.
- Keep the boring result. "No change" removes a suspect. It is not wasted time.
Fixes matched to the cause
| Evidence | Action worth testing | What not to do |
|---|---|---|
| First pass bad, repeat clean | Finish shader preparation, preserve caches, update the game | Delete shader caches after every session |
| GPU pinned, graph rough | Cap FPS below the sustained rate or lower GPU-heavy settings | Apply global "latency" registry packs |
| One CPU thread full, GPU drops | Reduce simulation, crowd or view-distance load; close the proven offender | Judge only by total CPU percentage |
| Texture-only change helps | Reduce texture pool pressure; verify storage and VRAM budget | Lower every setting and lose the evidence |
| Regular pulse disappears with one overlay | Leave that integration off or change its polling/capture mode | Disable Windows security components at random |
| Problem begins hot | Fix cooling, power mode or the confirmed limit | Hide the symptom with a higher fan speed before checking clocks |
Where PC Workman helps, and where it does not
PC Workman provides the system side of the story: CPU and GPU load, memory, temperatures, clocks, power and the processes active around the bad interval. Its in-game overlay can read FPS through RTSS when RTSS is running.
The current build does not capture a per-frame PresentMon trace or calculate 1% lows. For that part, use PresentMon or a front end built on it. Then compare the exact bad interval with PC Workman's sensor history. The split is honest and useful: one tool proves that a frame was late, the other helps explain what the machine was doing when it happened.
Short answers
Why does a game stutter when the FPS is high?
Because average FPS hides individual late frames. Shader compilation, streaming, a saturated CPU thread, VRAM pressure or a driver interruption can pause one frame without making the average look low.
Do 1% lows prove what causes the stutter?
No. They prove that a group of frames was slower. The timeline and matching system data identify the likely cause.
Should I cap FPS?
Test it when the GPU is constantly near its limit. Keep the cap if the same scene produces a flatter frame-time graph. A cap will not cure compilation or storage stalls.
Primary sources
- GameTechDev PresentMon, per-frame CPU, GPU and display performance capture.
- Microsoft DirectX: CPU- and GPU-boundedness.
- Epic Games: shader stuttering and PSO precaching.
- Unreal Engine texture streaming configuration.
If the whole PC feels slow while every graph looks normal, continue with the hidden bottlenecks guide →