How we built Focal, a GPU screen recorder for Windows
Focal is a screen recorder for Windows that makes recordings look edited without anyone editing them. We built it ourselves, from the capture code to the website, and it shipped in November 2026. The design rests on one decision: record the raw screen without the cursor, log the mouse and keyboard as data on the same clock, and apply every bit of polish (zooms, the cursor, captions, the frame) when the video is edited and exported, on the graphics card. This article walks through how that works and what it taught us about building serious desktop software.
If you want the short version of what the product does, the Focal case study covers it. This is the engineering story.
The problem with filming the cursor
Most screen recorders film everything you see, cursor included, into the video’s pixels. That is simple, and it is why their recordings are hard to improve afterwards. Once the cursor is part of the picture you cannot make it bigger, smooth out a shaky hand or zoom toward a click without zooming into a blurry arrow.
Focal records the screen with the cursor left out. Alongside the video it writes a log of where the cursor was, what shape it had, every click, every scroll and the timing of every key press. With that data the editor knows where the action is, so it can place zooms before the person opens the editor, and draw a clean cursor that moves smoothly at any size.
The catch is timing. If the log and the video disagree by even a few frames, the drawn cursor floats away from the button it is clicking. So the first piece we built was a single clock.
One clock for everything
Every track in a Focal recording is stamped with the same high-resolution timer Windows provides: screen frames, microphone audio, system audio, the camera and the input log. Pauses are removed from every track in exactly the same way. Nothing is lined up after the fact by guessing.
To prove it, we built a small test tool that flashes the screen white and plays a beep on each click. Recording it and measuring the result showed each flash arriving one to two frames after its click at 60 frames per second. That gap is the time the screen takes to repaint and be captured, not drift, so the timeline needs no correction. Microphone and video durations agreed within 5 milliseconds.
Keeping video on the graphics card
Recording a 4K screen at 60 frames per second is a lot of data. Copying every frame from the graphics card into normal memory and back would cost more than the rest of the work combined.
So in Focal, frames never leave the graphics card until they are compressed:
- Windows Graphics Capture hands over each frame as a texture (an image living in graphics memory), on a Direct3D 11 device created on the same graphics card that drives the monitor being recorded.
- The card’s video processor crops, scales and converts the colour format in place.
- The card’s own hardware video encoder (NVIDIA, AMD or Intel) compresses it.
Only the finished, compressed stream is written to disk, in a fragmented MP4 file. Fragmented means the file is playable up to the last second even if the computer crashes mid-recording, and Focal rebuilds an unfinished recording’s details the next time it starts.
On the machine we test with, a three-monitor setup with two 4K screens at different scaling settings, a full 4K recording ran at exactly 60 frames per second with no duplicated or dropped frames. Computers without a hardware encoder fall back to the processor, more slowly.
The same drawing code for preview and export
The edit itself is a small, plain description: which parts of the recording to keep, at what speed, where the zooms are, what the background looks like. That model lives in a pure Rust library with no graphics code in it, which makes it easy to test. It turns clicks and typing into zoom segments, then plays the camera through spring motion (the gentle ease in and out of a physical spring) so every zoom settles naturally instead of snapping.
Drawing happens in one Direct3D 11 compositor shared by the editor’s preview and the final export. Because they run literally the same code, what you see while editing is what the file contains. We did not have to chase differences between the two.
Exports decode, compose and encode on one graphics device. Measured on an NVIDIA RTX 3090:
| Recording | Export | Speed |
|---|---|---|
| 14.5 s at 1380 x 1000, cursor and clicks | 1080p H.264 with audio | 8x real time |
| 4K at 60 fps | 1080p H.264 | 3.1x real time |
| 4K at 60 fps | 4K HEVC | 3.3x real time |
The measurements also told us where not to spend time. Compositing was effectively free, at around 2,600 frames per second at 4K. The ceiling was the hardware encoder, and then decoding the recording. That is why later work went into talking to NVIDIA’s encoder directly and recording in HEVC, a newer format that decodes about twice as fast, rather than into optimising drawing code that was never the bottleneck.
The same habit drove the speed work in version 1.2. An edit now reaches the preview of an hour-long recording in about a hundredth of a second instead of a seventh. On an AMD Radeon integrated chip at 1920 x 1080, the slowest frame of a zoom went from about 65 to about 12 milliseconds, so zooms play smoothly on ordinary laptops. GIF exports run about two and a half times as fast on a 16-core desktop.
Native where it matters, web where it helps
Focal is a Tauri app. Tauri wraps a web interface, here written in React, around a Rust core, and produces a far smaller program than a browser-based framework that ships its own copy of Chrome. The editor, projects list and settings are React, because building rich interfaces is fast there.
The pieces that appear while recording are not. The region selector, countdown, control bar and camera bubble are native Windows windows drawn with Direct2D, and they are excluded from capture, so they never show up in the video. They need to appear instantly and stay out of the way, and a native window does that more reliably than a web view.
Shipping is part of the product
A desktop app that people pay for has jobs a website never has. Some of the ones we built:
- Installs without admin rights. Focal installs into the user’s own profile, with no drivers or services.
- Updates that check themselves. The app looks for a new version once a day, never during a recording or export, and verifies the installer’s signature before running it. Accepting an update to having the app back took about 3 seconds in our test.
- Release notes from the changelog. The entry for each version becomes both the update prompt and the public release text, so they never drift apart.
- A command-line twin. Every piece of the pipeline can be driven from a terminal tool, which is how most of the measurements in this article were taken and how problems get reproduced.
Version 1.0 shipped on 2 November 2026. By the next day the app was on 1.1, with a privacy tool, annotations and a music and voiceover track. Version 1.2 followed on 6 November with 138 changes: exports of just a part of a recording at up to 4K in any shape, one library across folders, full keyboard and screen reader support, and three rounds of polish on every screen. A fast cycle like that only works because the update path was built and tested before launch, not after.
What this means for software you might build
Most companies will never need a screen recorder. The lessons carry over to any serious build, though, including the data platforms and dashboards and internal tools we build for clients:
- Capture raw facts, decide later. Focal stores clicks as data instead of baking effects into pixels. A data platform does the same when it keeps raw records and builds reports on top, so a new question does not mean collecting everything again.
- Measure before optimising. We would have wasted weeks on drawing code that turned out to cost nothing.
- One source of truth for anything shown twice. Shared drawing code for preview and export is the same idea as defining a metric once for every dashboard.
- Treat shipping as engineering. Installs, updates, crash recovery and support tools are part of the product, not paperwork after it.
Focal also runs its speech recognition and privacy checks entirely on the user’s computer. We wrote that part up separately in running AI on the user’s computer.
Where to start
If you are planning desktop software, an internal tool or a platform that has to be fast and dependable, the useful first step is the same one we took: write down the one or two decisions everything else depends on, and test them before building the rest. Our app development page explains how we plan and build products like this, and you can get in touch to talk through yours.
Questions people ask
What is Focal?
Focal is a screen recorder for Windows built by VC Media. It records the screen without the cursor, logs clicks and keys as data, and adds smooth zooms, a sharp cursor, captions and a frame afterwards, all on the user's own computer.
What is Focal built with?
The recording, editing and export engine is written in Rust as about twenty small libraries, using Windows Graphics Capture, Direct3D 11 and Media Foundation. The windows people click around in are a Tauri app with a React interface, and focalcapture.com is an Astro site.
Why does Focal record without the cursor?
A cursor filmed into the video cannot be changed later. By logging the cursor's position, clicks and keys on the same clock as the video, Focal can draw a smoother, sharper cursor at export time and place zooms where the clicks happened, and every one of those choices can still be changed after recording.