VilkViral

Clarity. Structure. Financial Intelligence.

CapFrameX and FrameView: Diagnose PC Performance Like a Pro

Most PC gamers obsess over average FPS, yet average FPS is one of the least useful numbers you can look at when diagnosing real performance problems. What actually matters is how consistent those frames are — whether the GPU is churning them out in a smooth, predictable rhythm or lurching between fast bursts and agonizing pauses. That is exactly what CapFrameX and FrameView measure, and once you understand the data they produce, you will never troubleshoot a stuttering game the same way again.

Both tools are free, but they approach the job differently. CapFrameX, developed by the community around the Hardware Unboxed and Digital Foundry testing methodology, focuses on deep post-capture analysis with an intuitive chart interface. FrameView, released by NVIDIA, runs as a lightweight overlay and captures raw frametimes alongside GPU and CPU telemetry during a session. Together, they cover the full diagnostic loop: capture first, analyze second.

Understanding Frametimes Before You Touch Any Tool

A frametime is the number of milliseconds it takes to render one frame. At a steady 60 FPS, each frame takes roughly 16.67 ms. The moment one frame spikes to 50 ms, you have effectively dropped to 20 FPS for that instant — and your eyes catch it as a stutter even if the average counter still reads 58 FPS. This is why average FPS lies to you.

The metrics that actually reflect perceived smoothness are the 1% low and 0.1% low values. These represent the slowest one percent and one-tenth of one percent of frames captured, respectively. A gap of more than 30–40% between average FPS and 1% low is a reliable signal that something is causing periodic slowdowns — a CPU bottleneck, VRAM saturation, shader compilation stalls, or a driver scheduling issue.

Before running either tool, make sure you are testing in a reproducible scene. Fly-through benchmarks in games like Shadow of the Tomb Raider or Cyberpunk 2077 work well because they replay the same geometry each run. Open-world traversal is noisier and harder to compare across captures.

It is also worth understanding the relationship between frametimes and display technology. If you are running a G-Sync or FreeSync monitor, variable refresh rate will mask some frametime inconsistencies on screen, but the underlying spikes are still present in the data. Capturing frametimes with VRR active gives you a more realistic picture of the experience, while disabling VRR during a capture isolates the raw GPU output for a cleaner hardware comparison. Both perspectives have diagnostic value depending on what question you are trying to answer.

Setting Up FrameView for a Clean Capture Session

Download FrameView from NVIDIA’s developer page — it works on both NVIDIA and AMD GPUs, which is often overlooked. Installation is a simple unzip; no driver dependency is required beyond DirectX 11 or higher support.

Open FrameViewSetup.ini before your first run. The key settings to configure are:

  • OutputFolder — point this to a dedicated folder so captures don’t scatter across your drive.
  • Hotkeys — the default toggle is Scroll Lock, which works in most fullscreen titles but can conflict with some MMOs. Reassign to F10 if needed.
  • GPU and CPU telemetry — set EnableGPUTelemetry=1 and EnableCPUTelemetry=1 to capture clock speeds, power draw, and temperatures alongside frametimes. This data is invaluable when you suspect thermal throttling.

Launch your game, navigate to your test scene, press the hotkey to start capture, run through the benchmark or sequence, then press the hotkey again to stop. FrameView writes a CSV file for each session. That CSV is what you will load into CapFrameX. A good capture should last at least 60 seconds — shorter runs inflate variance and make 0.1% lows meaningless.

One detail that trips up new users: make sure your game is running in exclusive fullscreen mode rather than borderless windowed when testing. Borderless windowed routes frames through the Windows Desktop Window Manager, which can introduce its own scheduling latency and inflate frametime variance independently of the GPU’s actual render performance. If you are comparing settings, keep the presentation mode identical across every capture to ensure the data is directly comparable.

Loading and Reading Data in CapFrameX

CapFrameX can also capture natively using its own overlay (built on PresentMon), but its real strength is analysis. Install it, open the app, and drag your FrameView CSV into the Records tab. You will immediately see three panes: the raw frametime graph, the FPS percentile bar, and the statistical summary.

Start with the frametime graph. A healthy session looks like a flat line with minor oscillation. Any vertical spike above roughly 33 ms at 60 FPS target is a dropped or skipped frame. Clusters of spikes in the same time range often point to a repeating trigger — an AI routine, a chunk-loading event, or a shadow cascade update firing on a fixed interval.

The percentile bar gives you the full distribution from 0.1% low up to 99th percentile. In CapFrameX, hover over any bar segment to read the exact ms value and the corresponding equivalent FPS. When your 1% low is, say, 42 FPS while your average sits at 87 FPS, that 45-FPS gap tells a clear story: something is periodically throttling your render pipeline hard.

Use the trim slider at the bottom of the graph to exclude loading screens or menu transitions that contaminate the data. This is a step many users skip, and it can make a mediocre capture look artificially poor.

Comparing Captures Across Settings and Hardware

The comparison view in CapFrameX is where the tool separates itself from a simple spreadsheet analysis. Load two or more records, assign labels, and the overlay plots their frametime curves on the same timeline. This makes it trivially easy to answer questions like: does dropping from Ultra to High shadows actually reduce frametime spikes, or just raise average FPS?

A practical workflow I have used repeatedly: capture at native resolution with no upscaling, then capture again with DLSS Quality or FSR Quality enabled, and a third time with FSR Performance. Stack all three in CapFrameX. What you often find is that upscaling does not merely raise average FPS — it meaningfully compresses the spike distribution, which is what actually eliminates the perceived choppiness.

Render Mode Avg FPS 1% Low FPS Spike Frequency
Native 1440p 74 41 High
DLSS Quality 98 72 Low
FSR Performance 118 88 Very Low

Note that these are example values to illustrate the pattern — your actual numbers will vary by GPU, game, and scene complexity. The principle holds: compare at the percentile level, not just at the average.

Using GPU and CPU Telemetry to Pinpoint the Cause

FrameView’s telemetry columns — GPU utilization, CPU utilization per core, GPU power, and temperatures — become decisive when the frametime data shows a problem but the cause is ambiguous. In CapFrameX, open the Sensor tab after importing a FrameView CSV that was captured with telemetry enabled.

If GPU utilization drops sharply every time a frametime spike occurs, the GPU is being starved — a CPU bottleneck. If GPU utilization stays at 99% but power draw drops in sync with spikes, you are likely hitting a power limit or thermal throttle. If GPU utilization is normal but VRAM usage exceeds your card’s physical capacity, the game is streaming from system RAM over PCIe, which introduces the latency spikes you see in the frametime graph.

This is exactly the diagnostic path described in our deeper guide on CPU and GPU bottleneck identification and resolution — frametimes give you the symptom, telemetry gives you the cause. Without both data streams, you are guessing.

For AMD GPU users, note that FrameView’s AMD telemetry coverage is less complete than NVIDIA’s. In that case, run HWiNFO64 in parallel, log to CSV, and cross-reference timestamps manually in CapFrameX using the session duration as your alignment anchor.

Practical Diagnostic Scenarios and What to Do With the Results

Theory only goes so far. Here are three real scenarios where this workflow produces actionable outcomes.

Scenario 1 — Shader Compilation Stutter

You notice one-time spikes early in a session that never recur in the same scene. In CapFrameX, these appear as isolated 80–120 ms frametime spikes with no pattern. GPU utilization during the spike is near zero. This is DirectX 12 or Vulkan compiling shaders on first encounter. The fix is not a hardware upgrade — it is either accepting the compilation pass or enabling a game’s shader pre-compilation option if available.

Scenario 2 — VRAM Overflow at High Texture Settings

Frametime spikes appear repeatedly every 8–12 seconds. GPU utilization stays high during spikes. FrameView shows VRAM usage at or above the card’s rated capacity. Lower texture resolution or shadow map size to bring VRAM usage below 90% of physical capacity and re-capture. The spikes will flatten significantly.

Scenario 3 — CPU Bottleneck in a Dense Scene

Average FPS is reasonable but 1% lows collapse in crowd-heavy scenes. GPU utilization drops below 70% at exactly those moments. One CPU core shows 100% usage in the telemetry log while others sit idle — a sign the game engine is not distributing work across threads effectively. Raising resolution or enabling DLSS/FSR shifts more load to the GPU without changing the CPU-bound workload, which paradoxically improves 1% lows. If you also encounter in-game glitches from these sessions, the process for documenting and reporting them is outlined in how to report game bugs and use workarounds effectively.

Conclusion

Average FPS is marketing. Frametime distribution is engineering. CapFrameX and FrameView give you the engineering view — the data that separates a genuinely smooth 60 FPS from a stuttering mess that averages 60 FPS on paper. Start every diagnostic session with a clean, reproducible capture of at least 60 seconds, enable telemetry in FrameView so you have GPU and CPU context alongside frametimes, and use CapFrameX’s comparison view before changing any hardware. The answer to your stutter problem is almost always visible in the percentile bar before you spend a dollar on new parts.

FAQ

Is FrameView only for NVIDIA GPUs?

No. FrameView works on both NVIDIA and AMD GPUs for frametime capture. NVIDIA-specific telemetry columns (like GPU power via NVAPI) will only populate on GeForce cards, but the core frametiming data is hardware-agnostic.

What is the difference between CapFrameX’s built-in capture and FrameView?

Both use PresentMon under the hood for frametime capture. CapFrameX adds a richer overlay and direct in-app analysis, while FrameView is a lighter background process with more detailed GPU telemetry on NVIDIA hardware. Many users run FrameView for capture and CapFrameX for post-session analysis.

How long should a benchmark capture be for reliable 0.1% low data?

At minimum 60 seconds, but 90–120 seconds is better. The 0.1% low represents the slowest one-thousandth of frames, so a 60-second capture at 60 FPS gives you roughly 3,600 frames — meaning the 0.1% low is derived from about 3–4 data points. Longer captures make that number statistically meaningful.

Can I use these tools to benchmark a game after a driver update?

Yes, and this is one of the best use cases. Capture your baseline before installing a new driver, then re-run the identical sequence afterward. CapFrameX’s comparison view will show whether the driver improved or degraded your frametime consistency, not just raw FPS.

Do these tools affect in-game performance during capture?

FrameView’s CPU overhead is negligible — NVIDIA reports under 1% CPU usage during logging. CapFrameX’s overlay adds slightly more load when rendering on-screen metrics, but with the overlay hidden during a benchmark run, the impact is similarly minimal.

Should I disable background applications before running a capture?

Closing heavy background processes — browsers with many open tabs, video streaming clients, cloud sync services — reduces system RAM pressure and CPU scheduling noise that would otherwise contaminate your frametimes. Discord and lightweight monitoring tools like HWiNFO64 in logging mode have minimal impact and can stay running. The goal is to eliminate variables that are not related to the GPU, driver, or game setting you are actually testing, so that any change you observe in the data is attributable to the one variable you changed deliberately.