CapFrameX: reading frametimes from PresentMon and showing them over the game

The capture is PresentMon, and everything else is interpretation

CapFrameX captures, analyzes and compares game performance on Windows. What it is built on is stated in the first line: it combines Intel's PresentMon with hardware monitoring, frametime and FPS charts, and configurable overlays.

That division matters, because frametime measurement on Windows is a solved problem with a known implementation, and the interesting engineering is in everything around it. PresentMon hooks the presentation path, the app records the frame intervals, and CapFrameX turns those intervals into charts, comparisons and statistics, attaches the machine's state at the time, and puts the numbers on top of the game while it runs.

The user-facing configuration is short. The capture hotkey, the duration, sensor logging and the run history are all set in one place, and the process list determines which application is captured. The Info tab brings together CPU, GPU, memory and mainboard details with live telemetry, software component versions and platform security status, and can be copied straight from the dashboard.

The audience is therefore people who already care about frame pacing rather than just average frame rate: a player trying to find out whether a stutter is a real hitch or a reporting artefact, or a reviewer who wants a number that another person can reproduce. The README makes the reviewer case explicit, asking that CapFrameX be mentioned and linked, and offering a built-in screenshot function that adds the logo and name to analysis images.

The in-game overlay injects into the game, and it learns per game

Version 1.9.1 is the release the README describes in detail, and its headline is that it restores the experimental in-game overlay with digitally signed DirectX and Vulkan components for x64 and x86. It also bundles BENCHLAB Service 2.4.0 and updates PresentMon to 2.6.0, expands the Info dashboard and GPU telemetry, and updates overlay compatibility handling. The application runs on .NET 10.

The in-game overlay works by direct integration with the graphics APIs, which is why it needs signed components for both architectures. What is notable is the last line of the overlay section: the in-game overlay always learns which hook route works for each game, and this cannot be switched off.

That sentence describes a per-game compatibility database being built as a side effect of using the feature. The overlay has several ways of getting its data into the game's frame, and the ones that work differ per title, so the tool tries them and remembers. For a user, the cost of that design is that the overlay is doing something to the game beyond drawing on it, and the benefit is that it works on games where a simpler approach would not.

The signs of that complexity are everywhere in the troubleshooting list, which is the most honest part of the README. Overlay entries can be missing or show constant zero values, in which case the Overlay tab has a Reset button that restores all entries to a valid default state, and a Sort button that restores a clean ordering when entries have been rearranged. Overlay configuration files live at %appdata%/CapFrameX/Configuration/OverlayEntryConfiguration_(0/1/2).json and are recreated automatically on the next start if you back them up and rename them.

Hook-free is the default, in-game is the experiment, RTSS is a third path

The overlay renderer is chosen under Overlay, OSD options, and there are three of them, and the difference between them is not cosmetic.

The CapFrameX hook-free renderer is a built-in overlay without injecting into the game, and the README states it is the default for new configurations. It offers an output-display picker and a chart refresh control, which is what you need when the overlay is drawn on a second screen or a capture card rather than on top of the game.

The CapFrameX in-game renderer is the experimental one, with DirectX and Vulkan integration through the signed components, game compatibility profiles and hook-free fallback routing. The fallback routing is the interesting part: when the in-game route is not workable for a title, the tool can route to the hook-free path instead. Version 1.9.1 also lets you select in-game again if 1.9.0 migrated your in-game selection to hook-free.

The third option is RTSS, which uses RivaTuner Statistics Server and therefore has to be installed separately.

The honest framing of the trade is this. Hook-free is the safe default because it does not touch the game process, so it cannot cause a crash or trip an anti-cheat. The in-game renderer gives you a better integrated overlay, at the cost of injecting code into the process you are trying to measure. If you are benchmarking a competitive multiplayer title, that is a decision with consequences, and the README does not pretend otherwise.

The installer registers the Vulkan layers, the portable ZIP does not

There are two packages for the 1.9.1 release, and the difference between them is not only about where files land.

The installer package is a ZIP you extract and run CapFrameXBootstrapper.exe from. Setup installs the application and registers each Vulkan layer in its matching 64-bit or 32-bit HKLM registry view, which is the step that makes the in-game overlay able to hook into Vulkan titles. The portable package is the complete ZIP extracted and run with CapFrameX.exe, with portable.json kept beside it so that settings, captures and logs stay in the portable folder. Its Vulkan integration requires separate layer registration, which is the trade for not installing anything.

In short, the two entry points are:

CapFrameXBootstrapper.exe
CapFrameX.exe

The first installs and registers the Vulkan layers, the second runs from the folder you extracted it into.

Two other requirements are worth stating precisely. The .NET 10 Desktop Runtime x64 must be installed before running setup or the portable application, and the README is emphatic that it is required even if another .NET version or the plain .NET Runtime is already installed. The installer checks for it before proceeding.

For a portable update the README asks you to extract the package into a new folder, and then copy your Portable data folder and a customized portable.json if you need one. Extracting over the old folder is the wrong order, and the reason is that the old folder still contains the previous installation.

The signing story is part of the release, not a footnote. The packages contain stable application build 1.9.1.5, which adds missing Authenticode signatures to managed dependencies including LiveCharts.Wpf, and verifies every packaged Windows binary. CapFrameX binaries, the native overlay components, the bundled BENCHLAB executable and the setup are digitally signed with the CapFrameX publisher's Certum certificate, and separately installed BENCHLAB services remain supported.

The .NET runtime and the overlay conflict list are the real requirements

Two requirements in this project are not what a user would guess, and both are stated plainly.

The first is the runtime. The .NET 10 Desktop Runtime x64 is needed, and the plain .NET Runtime is not a substitute, because the application is a desktop application rather than a console or service. The README repeats this in the troubleshooting section, where the first tip is to make sure you are running the latest stable release and its required .NET Desktop Runtime.

The second is about other tools. The troubleshooting list warns that applications such as HWiNFO or AIDA64 that implement their own FPS or frametime metrics may conflict with the CapFrameX capture service, as they also rely on PresentMon-based mechanisms, and it strongly recommends disabling overlapping FPS or frametime monitoring features in those tools.

That is a genuine limitation of the design, not a documentation gap. If two PresentMon based collectors attach to the same presentation path, the frametime stream can be affected, and the resulting numbers are the ones you would publish. Any team that already runs hardware monitoring sensors on the same machine has to make a choice.

The rest of the troubleshooting list is a list of state resets, and it is worth skimming before reinstalling anything. Corrupted or outdated configuration files can be dealt with by closing CapFrameX, backing up the configuration, and renaming %appdata%/CapFrameX/Configuration/AppSettings.json so that the defaults are recreated on the next start, using the configuration folder specified in portable.json in portable mode. There is also a specific instruction about frametime anomalies after an update: close CapFrameX and any other capture tools before updating, and if a capture service is still running after the application exited, close the leftover PresentMon process before starting a new capture session.

A sponsor, a self-hosted build archive, and a licence GitHub cannot classify

The maintenance signals are healthy in one dimension and unusual in another.

The release history is steady. Version 1.9.1 was published on 2026-09-27, with a beta of 1.9.1 on 2026-09-19 and a 1.9.2 beta on 2026-10-04, and the last push to the repository was on 2026-10-15. The project also keeps development builds in its own build archive at archive.capframex.com, separate from the GitHub releases, which is a heavier commitment than most hobby projects make.

The sponsorship is a single named backer. The README states that CapFrameX is sponsored by Hone, thanks them for supporting the project and its continued development, and shows a Hone banner. A project with one commercial sponsor and a matching review request is not the same as an unfunded independent tool, and the terms of that relationship are not described in the README.

The licence is the other unusual point. The repository carries a LICENSE file, but GitHub's own classification for the repository comes out as a custom licence it could not map to a standard identifier. The README does not state the licence terms at all, so the file itself is the only place the answer exists, and anyone planning to use CapFrameX in a commercial or redistributed context has to read it before the question matters.

The repository structure also tells you what this is made of. There is a CapFrameX.sln at the root, a source directory, a separate benchlab-service directory, an external directory, a pmcreader-plugin directory, overlay-templates, a tools directory, a version directory, a PORTABLE_MODE.md, a portable.json.sample, and both AGENTS.md and CLAUDE.md for automated contributors.

Editorial conclusion

CapFrameX fits a Windows PC owner who needs frametime data they can trust, with the capture source named and the overlay in the same window, and it fits a reviewer who wants reproducible numbers with a chart rather than a number in a corner of the screen. It does not fit a Linux or macOS user, since the whole capture and overlay path is Windows specific, and it does not fit a machine where another PresentMon based tool is already running. Before you install, read the release notes for the package checksums, install the .NET 10 Desktop Runtime x64, and decide between the installer, which registers the Vulkan layers, and the portable ZIP, which does not.

Frequently asked questions

Official sources

1. CXWorld/CapFrameX on GitHub
2. Issues
3. README
4. Releases