Skip to content

Why Flashback Is Light

Riqqqque edited this page Oct 3, 2026 · 1 revision

Why Flashback Is Light

Most replay recorders cost you frames. Flashback is built so that the part running during your match does as little as possible, in a place where it can't get in the game's way, and everything else waits until you ask for it. This page is the short tour: each design decision, what it buys you, and where to read the details.

The result first

In the published Cyberpunk 2077 test at 1080p on one PC (Ryzen 7 9800X3D, RTX 5070), with every recorder set to a 60-second H.264 replay at 60 FPS and 20 Mbps:

Recorder Average FPS Cost vs recorder off 1% low vs recorder off Resident memory
Recorder off 149.69 — — —
Flashback 0.6.22 140.92 −5.86% −0.85% 238.9 MiB
Medal 2630.351.1 109.23 −27.03% −22.69% 1,313.7 MiB
ShadowPlay 11.0.8.299 107.18 −28.40% −24.42% 500.2 MiB*

Where another recorder won: Medal's process used slightly less CPU (0.52% against Flashback's 0.59%), and its GPU drew less power (182.1 W against 194.1 W) while rendering fewer frames.

*ShadowPlay's figure covers only its listed processes; NVIDIA's driver and overlay do part of its work.

These numbers describe Flashback 0.6.22 on one PC and one game. Today's Flashback uses a newer capture path that hasn't been through this comparison yet, and no recorder has zero cost. The full table and method are on Benchmarks.

The design, decision by decision

  your game  ---------------------------------------------------------->  GPU renders
                                                                              |
  Flashback capture worker (separate, headless process)                      |
     display capture --> one GPU copy --> hardware encoder --> MP4 segments on disk
     (paced to your output FPS)          (GPU media engine)        |
                                                                    |  only when you press save
  Flashback app (asleep most of the time)                           v
     hotkeys, game name, library  <--------------------  stream copy, no re-encode --> clip

1. Record the display, never the game

Flashback captures your monitor through Windows' own capture APIs. It never injects code into a game, never hooks rendering, and never reads game memory. Nothing of Flashback's runs inside the game's frame loop, so there's nothing there to slow it down, and the same path works for DirectX, Vulkan, OpenGL and Java games.

More: Capture Pipeline · Anti-Cheat and Games

2. Encode on the GPU's media engine

Video is encoded by your graphics card's dedicated encoder (NVENC, AMF or Quick Sync, through Windows Media Foundation), which sits beside the 3D engine your game uses rather than competing with it or with your CPU. In the published test, Flashback's GPU video-encode load was 7.56%.

More: Hardware Encoding

3. Capture only the frames you'll keep

A 480 Hz monitor produces 480 images a second, but a 60 FPS clip needs 60. Flashback paces capture to the frame rate you record, not your monitor's refresh rate. When this arrived, on a 480 Hz display at 1080p60, the recorder's 3D-engine load fell from 5.634% to 1.805% and its CPU from 1.676% to 0.900%.

More: Capture Pipeline

4. Touch each frame once

Each frame is scaled straight into the capture surface and copied once into the encoder. It used to be scaled into a temporary image and copied three times. On the test PC that cut Flashback's share of the GPU by about 12% with the cursor hidden. Partial screen updates use the GPU's copy engine instead of a 3D draw, and a fixed pool of eight GPU samples is reused, so nothing is allocated per frame.

More: Capture Pipeline

5. Keep capture in its own small process

A separate, headless capture worker owns screen capture, the encoder and audio. It has no window, no network client, no updater and no Cloud session. The app around it can open its window, draw thumbnails or run the editor without adding a byte to the worker, and a worker that stalls can be replaced without losing the window, hotkeys, library or the replay you already have.

More: Isolated Capture Worker · Architecture Overview

6. Save by copying, not re-encoding

The replay lives on disk as short, finished MP4 segments. Pressing save copies the span you asked for out of those segments with stream copy: no decoding, no re-encoding, no quality loss. A clip is ready within seconds, with almost no CPU or GPU spent.

More: Replay Buffer and Segment Rotation

7. One encoder, kept alive

On compatible NVIDIA hardware with H.264, one encoder and one Direct3D device stay alive across segment rollovers, and only the output file rotates on a clean keyframe. Other GPUs and codecs use a per-segment path that prepares the next encoder off the capture thread. Either way, capture never stops between segments.

More: Replay Buffer and Segment Rotation

8. Everything else stays asleep

The window, editor, thumbnails, capture-health checks, exports and Cloud don't run until you open them. When Flashback starts hidden in the tray, its full window isn't even loaded. Work that does run in the background (voice recognition, input-overlay observation, compression, health analysis, Cloud preparation, FFmpeg) runs at below-normal priority, so the game wins whenever they compete. With nothing queued, Cloud makes no network requests.

More: Architecture Overview · Built on .NET 10

9. Guards that watch the right thing

Flashback measures the capture worker on its own, against a settled baseline, so opening the editor never looks like a recorder leak. If the worker's memory, handles or threads really do grow, it's replaced at a clean segment boundary. If something hangs, only the worker is stopped.

More: Resource Guards and Recovery

Honest limits

  • Not zero-cost. Capture still uses some GPU, encoder, CPU, memory and disk bandwidth. Flashback works to keep that small and measures it.
  • One PC, one vendor. All published measurements are on an NVIDIA RTX 5070. There are no published AMD or Intel figures yet.
  • Settings matter. 4K and 240 FPS are heavy for any encoder; Flashback warns you when a profile is too demanding rather than saving uneven clips.

See Known Limitations.

What "state of the art" means here

Not a slogan: a capture worker isolated from everything else, frames encoded by the GPU's own media engine and touched once, capture paced to what you keep, and saves that copy finished segments instead of re-encoding them. Each of those choices is measured, and the measurements, including the ones Flashback loses, are published.

Related pages

Benchmarks · Architecture Overview · Capture Pipeline · Hardware Encoding · Isolated Capture Worker

Clone this wiki locally