How to Fix Menus Running at Hundreds of FPS and Draining the Battery

On the main menu a laptop's fans spin up because the screen renders at 600 FPS for a static UI. The cap is gameplay-only. Cap menus low to save power and heat.

How to fix it

1. Cap when in menu

When you enter a menu-only state, set Application.targetFrameRate to a low value (with VSync off so it takes effect) since a static UI does not need high refresh.

2. Restore on gameplay

On returning to gameplay, set the cap back to the player's chosen target so you do not accidentally lock the game at the menu rate.

3. Consider on-demand rendering

For fully static menus, render on demand (only redraw on input) so the GPU idles between interactions instead of redrawing identical frames.

Catching the ones you can't reproduce

The hardest version of this to fix is the one you can't reproduce — it only happens on a player's hardware, OS, driver, or save state, under conditions that simply aren't present on your machine. A report that says “it crashed” or “it froze” gives you nothing to act on, so the bug survives release after release while quietly costing you players.

Automatic error capture closes that gap. Each failure arrives with its full stack trace, the device and OS, the build number, and a breadcrumb trail of what the player did right before it broke, so even a failure you have never seen becomes a specific, reproducible issue. Fold identical failures into one signature ranked by how many players each hits, and your worklist sorts itself worst-first instead of arriving as a stream of vague complaints.

This is where a tool like Bugnet earns its place. Its SDK captures every Unity error automatically with the full stack trace plus device, OS, memory, build, and game-state context, folds duplicates into one grouped issue with an occurrence count, and ties each to the build it first appeared on — so you fix the problem that hurts the most players first and confirm it is gone when its signature disappears from the next release.