Built on NET 10

Built on .NET 10

Flashback 0.8.0 moves the app, its tests and its release tooling to .NET 10. This page explains what that means for you, how the app is packaged, and why the runtime isn't where a recorder's weight comes from.

What you get

• Nothing extra to install. Flashback ships self-contained: the .NET 10 runtime it needs is inside the app folder, and so are the Microsoft Visual C++ runtime files its native capture engine uses. You don't need to find, install or update a separate runtime, setup has no prerequisite step, and other software on your PC can't break Flashback by changing a shared runtime.
• Faster start. The app is published ReadyToRun, which compiles it ahead of time to native x64 code so less work happens when it launches.
• A current, supported runtime. .NET 10 is the long-term-support release, with current security fixes.
• Your settings carry over. Moving runtimes doesn't change where clips or settings live.

How it's built

Runtime	.NET 10 (net10.0-windows)
Interface	WPF, with Windows Forms interop
Architecture	x64 only (win-x64)
Packaging	Self-contained, ReadyToRun, no debug symbols in the release
Capture engine	Native C++ (a Flashback fork of ScreenRecorderLib), running in the capture worker
Media tools	Flashback's own FFmpeg build, run as separate processes

The worker is the same Flashback.exe started in a private mode, so the runtime ships once, not twice.

Why .NET isn't the weight

It's a fair question: why build a lightweight recorder on a managed runtime? Because the managed part is small, and the heavy lifting never runs in it.

When Flashback's memory was broken down on 0.6.9 (before the capture worker split and the move to .NET 10; window hidden, recording 1440p60 with system audio and a microphone), the single process used roughly 253 to 284 MiB in total, and only about 14.5 MB of that was the .NET managed heap. The rest was native: Windows display capture, Media Foundation, audio, the hardware encoder, and the WPF interface. Today the native capture work lives in the separate capture worker, but the split between a small managed heap and native media memory is the same idea.

 what runs where
 ---------------
 .NET (managed)     settings, game detection, segment bookkeeping, saves,
                    library, UI, updates           -- small, mostly idle
 native, in worker  display capture, GPU scaling, hardware encoding,
                    audio capture, MP4 writing     -- every frame
 separate process   FFmpeg / FFprobe for saves, trims and exports

Every frame of video stays in native code and on the GPU, from capture to encoder to disk. The .NET side handles decisions and bookkeeping a few times a second, not pixels.

Things kept out of the startup path

• When Flashback starts hidden in the tray, the full window and the editor aren't loaded.
• Cloud sign-in, upload and preparation code isn't created until you open the Cloud tab or upload. The small upload queue that starts with the app makes no network requests while nothing is queued.
• The editor's decoder, storyboard and timers exist only while you're editing.
• Thumbnails live in a small in-memory cache.

Safer defaults

• BinaryFormatter stays off. It's explicitly disabled in the build, and on .NET 10 the in-box implementation can't run at all. Flashback also stopped using the clipboard format that depended on it.
• Policy in code you can't swap. Update-verification keys and policy are compiled into the app. See Update security chain.

What we don't claim

There's no published measurement of .NET 10 making Flashback's recording faster, and none is claimed here. The recorder's performance comes from the capture and encoding design described in Why Flashback is light, and the measured numbers are on Benchmarks.

---

Related pages: Architecture overview · Isolated capture worker · Benchmarks