Test Methodology
What a reproducible Radiant Optimizer performance test must record and disclose.
Last updated: 2026-10-10
Current test status
Hands-on testing is pending. No real Radiant Optimizer benchmark result has been published on this site. Use the capture comparison workspace to record your conditions and analyze your own files. The analyzer’s optional sample is synthetic data, not a product benchmark.
Record the complete context
Each published test must include CPU, GPU, RAM, operating system edition and build, driver version, game version, optimizer version, resolution, graphics preset, exact settings changed, test scene or replay, test date, number of repeated runs and links to raw records.
We do not fill unknown fields with guessed hardware or software versions. An editorial update date is not a test date.
Compare equivalent runs
Establish the original baseline and repeat the same scene under matching conditions before and after the recorded changes. Keep background activity and relevant temperatures in the records, avoid combining unrelated changes, and include enough repeated runs to reveal variability.
Average FPS and 1% low require a stated calculation method. Frame-time plots must come from raw frame records rather than a conversion of average FPS. A calculation of 1000 / FPS gives an equivalent frame duration; it cannot reproduce actual frame-time spikes.
Report every outcome
Publish improvement, unchanged results and regressions with their conditions and variability. Do not turn a favorable single run into a universal product claim. Record exclusions and limitations explicitly.
Sources and corrections
Product versions, pricing and download sources require their own verification. Browser project source checks are independent from software performance testing.
Contact support@radiant-optimizer.app with questions about a method, a source or a reported result.
FPS tool calculation
The FPS analyzer processes selected files locally in a browser worker. It does not upload the capture data. Its default sample is a synthetic illustration, not a published benchmark or evidence of an optimizer improvement. Importing a file does not verify its authenticity.
Supported CSV columns are Application, ProcessID, SwapChainAddress and MsBetweenPresents (case-insensitive), or the millisecond timestamp column CPUStartTime. The tool groups records by application, process ID and swap chain. If more than one usable stream is present, select one stream per file before viewing metrics. See the PresentMon console documentation and the 1.x column definitions.
MsBetweenPresents measures the interval between Present calls. When only CPUStartTime is available, the tool differences successive timestamps within each stream and labels the result CPU cadence. Neither metric proves the number of frames physically displayed. Display duration and GPU execution time are not substituted for these intervals.
For N valid intervals with a total duration of T milliseconds, average FPS = 1000 × N / T. Sort the intervals from longest to shortest and take the first ceil(N × 0.01) values. 1% low FPS = 1000 / the mean duration of those slowest intervals. This differs from simply inverting the 99th percentile.
Empty, non-finite, zero and negative interval records are excluded and counted. The first timestamp-only record has no preceding interval and is also counted as an initial excluded record. All positive intervals, including long pauses and spikes, remain in the statistics. The duration shown is the sum of valid intervals, not a verified wall-clock recording length. Invalid CSV structure or backwards CPU timestamps cause an error. Each file is limited to 100 MB, 1,000,000 records and 256 streams.
The chart uses elapsed valid interval time on the horizontal axis. For large captures it retains the first, last, shortest and longest intervals in each sequential bucket. This preserves spikes while reducing the trace to at most 2,400 points. All original valid intervals contribute to the metrics. The headline metrics describe the after-changes stream when one is provided, otherwise the baseline. Metadata fields are user supplied and are not verified against the capture. Compare the same scene, settings and capture metric over repeated runs; a single difference is not evidence of causation.
The separate browser test runs a fixed 160-particle Canvas 2D scene, warms up for one second and records animation callback intervals for fifteen seconds. It measures requestAnimationFrame callback cadence, not another application's FPS, GPU throughput or physically displayed frames. A hidden tab, lost window focus or window resize invalidates the run. Device, browser, viewport and display refresh limits affect results; keep these fixed when comparing runs.