A frame-rate tool creates lock-in when performance history cannot be exported, metric definitions are opaque, or the same benchmark cannot be repeated with another tool. Check raw per-frame export, documented units and calculations, benchmark ownership, supported graphics paths, automation interfaces, licensing, and a tested comparison with an independent capture method.
Demand raw, labeled performance data
A screenshot of average frames per second is not a portable record. Require export of per-frame or suitably detailed observations with timestamps, frame durations, presentation status, application and process identifiers, test labels, and the environment metadata needed to reproduce the run. Confirm the format is documented and can be read without an active subscription.
The open PresentMon project captures CPU, GPU, and display frame durations and latencies across several graphics APIs and hardware configurations. Its console application can output CSV files, while its capture application can produce per-frame CSV data. See the PresentMon repository. A tool does not need to use PresentMon, but portable structured output provides a useful comparison point.
NVIDIA describes FrameView as collecting more than 40 metrics and saving benchmark logs and summary files that reference the run. See NVIDIA FrameView. Before adopting any tool, export a sample and verify that the raw evidence remains understandable outside the vendor's dashboard.
Inspect metric definitions and limitations
Ask how the tool defines rendered, presented, and displayed frames; dropped frames; frame time; percentile or low-frame metrics; latency; power; and generated frames. Record which graphics APIs, window modes, overlays, upscalers, frame-generation systems, variable-refresh configurations, and hardware vendors are supported. A proprietary score with no formula cannot safely anchor a long-term baseline.
Document known limitations by environment. PresentMon, for example, publishes limitations affecting some OpenGL or Vulkan instrumentation and some metrics under hardware-accelerated GPU scheduling. A vendor that hides limitations makes cross-version comparisons harder and can trap the team in unexplained historical numbers.
Check automation and ownership
Verify command-line or API access, unattended licensing, stable identifiers, exit codes, capture start and stop controls, version pinning, and retention of installers or release notes. Ensure the organization owns the benchmark route, scene, save file, scripts, configuration, result archive, and acceptance thresholds. If those assets live only in a vendor cloud account controlled by one employee, portability is weak.
Review pricing for raw export, API calls, team access, longer retention, and CI use. Confirm what happens to stored results after downgrade or cancellation and whether deletion can be delayed until a verified export is complete.
Prove a baseline can move
Capture the same stable scene with the current tool and an independent tool under matched conditions. Do not expect identical numbers when definitions differ; instead, document the relationship, gaps, and limitations. Preserve both raw datasets, tool versions, environment details, and the decision about a replacement baseline.
A healthy exit plan can reproduce the benchmark, explain every required metric, preserve historical evidence, and continue release gates without the original vendor. If any of those fail, record the dependency explicitly rather than treating a downloadable chart as portability.
Sources
- PresentMon — GameTechDev
- FrameView Performance and Power Benchmarking App — NVIDIA