An estimator that starts from a real measurement
Most performance tools invent frame rates from component names. This one refuses: there is no honest way to derive FPS from a parts list, because it depends on the game, the settings, the drivers and the scene. What can be done honestly is scale from a measurement. Enter the frame rate you (or a benchmark you trust, for your hardware and settings) actually measured at one resolution, choose the resolution you are considering, and this estimator models the change three ways (graphics-bound, mixed and processor-bound), shows the frame time and pixel counts behind it, and tells you plainly which scenario fits your workload. It cannot invent frame rates; it can project yours.
Your measured baseline
The resolution you are considering
A second target to compare (optional)
Disclaimer: This calculator gives estimates for general information only. It is not financial, medical or other professional advice. Projections scale from the measured figure you provide and cannot predict a specific game’s performance on specific hardware; treat them as planning ranges, not benchmarks.
What this calculator does
It projects how a known frame rate moves when resolution changes, which is the one performance question that arithmetic can genuinely answer, because resolution is pure pixel count and pixel count is the graphics card’s workload. It takes your measured baseline (a frame rate at a resolution, on hardware and settings you specify by measuring them), computes both resolutions’ pixel counts, and models the move under three stated assumptions: fully graphics-bound, where frame rate scales exactly inversely with pixels, fully processor-bound, where it does not move at all because the processor was the limit at both sizes, and the mixed case in between, modelled at the square root of the pixel ratio. Every scenario is printed whether or not you headline it, together with the frame time in milliseconds and, if you give a refresh rate, an honest note on whether the estimate reaches it. What it will not do is accept a CPU and GPU model name and output a frame rate: that number would be fabricated, however many charts dress it up, and the brief for this page forbids it in terms.
How to use it
- Measure on your own hardware if you possibly can. Run the game, in the scene type you actually play, for a few minutes at your current resolution, and average the frame rate. A benchmark video using your exact card and settings is the acceptable substitute; a different card’s review is background reading, not a baseline, and entering one builds the projection on someone else’s machine.
- Choose the scenario by the game, not by hope. Esports titles at competitive settings chase hundreds of frames and lean on the processor. Big single-player games at ultra settings lean on the graphics card until the resolution drops. Strategy and simulation titles sit on the processor whatever the pixels do. When genuinely unsure, headline Mixed and read the other two rows as your corridor of outcomes.
- Frame time is the feel. FPS averages hide stutter; frame time (1000 / FPS, in milliseconds) is closer to what smoothness is. The results give the headline estimate’s frame time, and a jump from 11 ms to 44 ms explains a change in feel that “90 down to 22” understates emotionally and overstates nothing.
- The refresh check is about waste in both directions. An estimate far above your monitor’s refresh is frames you paid for and never see; an estimate below it is a monitor underfed. Neither is automatically wrong (headroom today is tomorrow’s heavier game) but the note makes the trade visible before a purchase makes it permanent.
- Settings changes are outside this model, deliberately. Dropping shadows or textures changes the workload per pixel, which pixel arithmetic cannot know. If you plan both a resolution and a settings change, apply them one at a time: project the resolution here, then measure again at the new settings when you can.
How it is calculated
- Pixel counts: baseline pixels = baseline width x height; target pixels likewise. Graphics-bound estimate = baseline FPS x baseline pixels / target pixels. Mixed estimate = baseline FPS x the square root of that ratio. Processor-bound estimate = baseline FPS unchanged. Frame time = 1000 / headline FPS, in milliseconds. Estimates round to two decimals.
- The model changes exactly one variable (resolution) and says so. Memory capacity, bandwidth, engine behaviour per scene and driver changes are all outside it, which is why the output is a scenario table rather than a single promised number.
Worked examples
90 measured FPS at 1080p, considering 4K. 1080p is 2,073,600 pixels; 4K is 8,294,400, exactly four times the pixels. Graphics-bound, the estimate is 90 / 4 = 22.50 FPS, a frame time of 44.44 ms. Mixed, it is 90 / 2 = 45.00 FPS. Processor-bound it stays 90. The three rows together are the answer: unless the game was processor-limited, 4K costs most of the frame rate, and any tool quoting a single number for this move is choosing a scenario without telling you.
The same baseline, considering 1440p. 1440p is 3,686,400 pixels, 1.78 times 1080p. Graphics-bound: 50.63 FPS. Mixed: 67.50 FPS. Against a 144 Hz monitor both fall short, which the refresh note states; against the 4K figures above, 1440p is the visibly gentler step, which is the comparison the second-target field exists to make side by side.
A processor-bound case. A simulation measured at 60 FPS at 1080p stays near 60 at 1440p in the processor-bound row, because the processor was simulating the same world regardless of pixels. If your real measurement at the new resolution lands near the graphics-bound row instead, the game was never processor-bound, and the table has just taught you your bottleneck empirically, which is more than most “bottleneck calculators” ever do.
Reading your results
Read the corridor, not a row. The graphics-bound and processor-bound rows are the plausible extremes for a pure resolution change, and reality for your game sits between them, usually nearer the row matching its genre. Read the headline you chose as your planning figure and the corridor as your uncertainty, and size purchases for the corridor’s lower half when the money is large. When the measured reality later disagrees with all three rows, the baseline was the problem (a different scene, thermal throttling, a driver change), not the arithmetic, and re-measuring in a matched scene is the fix.
Limitations
- One variable only. Resolution is modelled; settings, hardware changes and game updates are not. A card upgrade changes the baseline itself, so measure on the new card before projecting its resolutions.
- Averages, not distributions. The baseline is an average frame rate, and the projection scales the average. One-percent lows and stutter (which decide how a game feels at the margin) do not scale as predictably and are not claimed here.
- The mixed model is an interpolation, labelled as one. Square-root scaling is a planning heuristic between two defensible extremes, not a law of engines. It is printed alongside the extremes so its status is impossible to mistake.
- Memory limits can cliff-edge. If a target resolution pushes a game past your card’s memory at your texture settings, performance can fall far below the graphics-bound row. Pixel arithmetic assumes the workload per pixel is constant; out-of-memory behaviour breaks that assumption entirely, and only a benchmark of your card sees it coming.
Frequently asked questions
Why will this page not estimate FPS from my CPU and GPU names?
Because that number cannot be honestly produced. Frame rate for a component pair depends on the game engine, the exact scene, settings in the dozens, resolution, drivers, thermals and background load; published “estimates” for part names are typically scraped, averaged across incomparable tests, or simply invented, and they dress the result as a precise figure. The defensible calculation is the one offered here: scale from a measurement of your hardware in your game. It gives a narrower answer to a narrower question, and unlike the invented figure, it is actually connected to your machine.
What is a bottleneck percentage, and why is there none here?
Sites that output “your CPU bottlenecks your GPU by 23%” are converting a workload-specific, scene-specific relationship into a single portable number that does not exist. In one game a pairing is graphics-limited at 4K and processor-limited at 1080p competitive settings; both facts about the same parts disprove the single percentage. This page shows the honest version of the same idea as scenarios: if your workload is processor-bound, resolution barely moves the frame rate; if graphics-bound, it moves it by the pixel ratio; and your own measurements at two resolutions can tell you which.
How do I measure a baseline worth using?
Pick a repeatable scene (a built-in benchmark if the game has one, otherwise a fixed route through a busy area), run it at your current resolution and settings for two or three minutes after the game has warmed up, and average the frame rate from an overlay or the game’s own statistics. Avoid menus, loading screens and empty sky, which inflate the figure. Repeat once; if the two runs differ wildly, something else (thermals, background tasks) is in the measurement and should be fixed before it is projected anywhere.
Does higher resolution always cost frame rate?
Only when the graphics card is the limit, which the scenarios make explicit. The processor-bound row exists because whole genres (simulation, strategy, high-refresh competitive play) spend their frame budget on computation rather than pixels: their frame rate is nearly identical across resolutions until the card finally saturates. The practical consequence cuts both ways: a monitor upgrade is not automatically a card upgrade, and the decision deserves the five minutes this projection takes over the alternative of finding out after purchase.
Related calculators
Method: scenario scaling from a user-measured baseline by exact pixel ratios, with the interpolation model and its limits stated on the page; no component-name performance data is used or implied. Last reviewed: 13 October 2026.