Conceptual illustration: Mais FPS, created with AI.
The counter looks healthy. Then you turn a corner, the camera catches on an invisible nail, and your expensive graphics card briefly feels like a bad internet connection. An average can describe that session accurately while completely underselling the bit that annoyed you.
Before shopping for an upgrade, give the interruption a timeline. A frametime graph and a repeatable route are usually more useful than another screenshot of the FPS counter. The aim is to discover when the game hesitates, which changes affect it, and whether the problem even follows the GPU.
The spike matters more than the headline
In an ideal evenly paced sequence, 120 FPS means a new frame every 8.33 milliseconds; 60 means 16.67 milliseconds. These are arithmetic examples, not benchmarks. A single 80-millisecond pause in an otherwise fast run can be obvious while barely denting the average. The graph shows where that pause happened.
A 1% low summarizes the slow end, but implementations differ: some average the slowest fraction, while others use a percentile or time-based approach. CapFrameX documents those differences. Compare the same metric from the same tool; a 1% low is neither the slowest individual frame nor a diagnosis.
That distinction also saves you from false victories. If a settings change lifts the average but leaves the same ugly spikes at the same doorway, it has improved throughput without solving your complaint. Keep both observations.
Give the hitch a fair trial
Here is a suggested home-testing routine, not a claim that MaisFPS has benchmarked your game:
- Pick a save and a route lasting roughly one or two minutes. Include the troublesome area, a camera turn and some representative combat.
- Write down the game and driver versions, resolution, upscaling mode, graphics settings and frame cap. Disable frame generation for this initial diagnosis.
- Let any visible shader-preparation process finish. Record the first traversal separately, then capture three repeat runs under the same conditions.
- Save the average, the precisely named low metric and the frametime trace. Note where each visible hitch occurred.
- Change one setting group and repeat the route. Compare the range across runs, rather than picking the prettiest result.
Keep menus and loading screens outside a gameplay capture unless you are investigating those transitions. Close an unnecessary download or recording session, but do not dismantle Windows before establishing a baseline. Testing should make the problem easier to understand, not introduce five new variables.
Read the clues without appointing a culprit
PresentMon’s documentation distinguishes frame timing, GPU Busy time and displayed-frame measurements. GPU Busy describes time the GPU spent working on a frame. Availability and interpretation depend on the capture path; read the tool’s labels rather than treating every overlay number as interchangeable.
Now lower render resolution while keeping the rest consistent. If frame delivery improves substantially in the difficult section, GPU rendering load deserves attention. If the hitch survives almost unchanged, investigate elsewhere too. A frame cap can deliberately leave the GPU idle, so low utilization alone cannot convict the processor.
Intel’s GPU–CPU profiling guidance uses workload timelines and queue gaps to distinguish limits. For a player, the practical lesson is modest: combine timing with what changes the result. A utilization percentage by itself leaves too much out.
First encounter or every encounter?
A hitch that appears when an effect first explodes, then disappears on repeat, is a different lead from a slowdown that returns in every crowded fight. Epic explains that just-in-time shader compilation can interrupt rendering, and that driver caches help subsequent encounters. That pattern is a clue, not proof that every first-run pause is a shader problem.
Hitches when entering new areas may also involve asset streaming, storage, memory pressure or game code. Compare texture quality separately from resolution. Check whether the game is on the storage type it recommends and whether other tasks are competing for it. If performance worsens after a long session, record temperatures and clocks rather than assuming the launch benchmark tells the whole story.
Multiplayer adds another trap: rubber-banding can occur while local frame delivery stays smooth. A stable frametime trace during the visible disruption is a reason to examine network or server behavior before replacing hardware.
Spend after the pattern repeats
A clean result is something like: “This route hitches on every pass with this texture setting, and improves consistently one step lower.” That gives you a practical setting today and a useful question for reviews tomorrow.
Sometimes the answer is a faster component. Sometimes it is a game patch, a completed compilation pass, or a sensible cap that your machine can sustain. Keep the graph until you have tested the fix, then hide the overlay and play. A successful diagnosis should eventually give you fewer numbers to watch.
