I'm 19 and I Built a Screen Studio Alternative for Linux with Rust and wgpu, Here's What I Learned
I got tired of waiting for someone else to build it.
If you're on macOS and record videos for your dev blog or your product, you've probably used Screen Studio. It's polished, it exports beautifully, the zoom animations feel intentional. On Linux you get OBS (which is powerful but built for streaming, not short product demos) or some GNOME recorder that exports a flat .webm. That's it.
I'm Mathis. I'm 19, I do indie dev full-time, and I spent the last few months building Screenix, a screen recorder and video editor for Linux with automatic zoom, cursor tracking, and clean export. I built it in Rust with wgpu for rendering. I have 2 paying customers so far and a long list of things that were harder than I expected.
This post is about the hard parts.
Why Rust and wgpu
Not because I wanted to suffer. Rust felt like the right call for a native Linux app where I needed direct control over rendering, memory, and system APIs. I didn't want to wrap Electron around everything or fight with GTK's rendering pipeline when I needed frame-accurate video output.
wgpu gave me a portable GPU abstraction that works on Vulkan on Linux and could potentially work on other backends later. The learning curve was steep, but once the mental model clicked, the control it gave me over the rendering loop was worth it.
The Hardest Part: Wayland Cursor Tracking
This is where I spent probably the most unexpected amount of time.
On X11, getting the cursor position is straightforward. On Wayland, the compositor controls everything and doesn't just let you query a global cursor position whenever you want. This is by design for security, but it makes building a screen recorder genuinely annoying.
My first approach was a GNOME Shell extension. I wrote a small extension that exposed the cursor position over D-Bus, and Screenix would query it from the extension. It worked, but it meant requiring users to install and enable a separate extension before they could even start recording. Not ideal for a product that's supposed to feel polished.
I eventually moved the position tracking to use the SPA (Simple Plugin API) metadata, which is part of the PipeWire ecosystem. PipeWire is the audio and video routing layer that modern Linux desktops use, and SPA metadata lets you attach arbitrary data to streams, including pointer position. This was cleaner because if you're capturing the screen through PipeWire anyway (which you are on Wayland), the cursor position can travel with the stream without needing a separate channel.
But there's a catch: I still use the GNOME Shell extension for the cursor shape.
The cursor shape (whether the cursor looks like an arrow, a hand, a text cursor, etc.) is separate from the position. PipeWire doesn't expose this. The Wayland protocol has a cursor-shape protocol, but getting the shape of the cursor as seen by another application, not your own, requires compositor cooperation. The extension is the only reliable way I found to get this on GNOME Wayland. So there's still a dependency, just a reduced one.
If you know a better way, I genuinely want to hear it.
What Went Wrong with the Editor Engine
The editor is where the product actually differentiates itself from "just a recorder." You record, then you get a timeline where you can add zoom effects, adjust the cursor smoothing, and export.
The zoom system was conceptually simple: track the cursor, add smooth keyframes around fast cursor movements, scale the viewport. In practice I had to think carefully about when to trigger a zoom (not every mouse movement, that would be seizure-inducing), how to smooth the easing so it doesn't feel mechanical, and how to handle recordings where the cursor barely moves versus recordings where it's flying across a 4K display.
The manual zoom layer I built on top of the automatic one took longer than expected because I needed a good interaction model. You scrub the timeline, you set a zoom region, you adjust it. Getting this to feel responsive in the editor while not killing export performance required separating the preview rendering from the export pipeline.
Export speed is still something I'm actively working on. The bottleneck right now is in how I'm handling frame composition before encoding. I haven't fully optimized the wgpu pipeline for batch frame output yet.
What I Underestimated
A few things I thought would be easy that weren't:
Fedora support. PipeWire versions and GNOME versions vary more than I expected between Ubuntu and Fedora. Things that worked on one didn't work on the other. I ended up having to test both and handle some version-specific paths explicitly.
The extension installation UX. Even with the reduced dependency, asking users to install a GNOME extension is friction. A lot of people don't know how to do it, or they're on a locked-down system, or they're not on GNOME at all. I need a better fallback story for non-GNOME Wayland compositors. KDE Plasma handles things differently.
Being the only person working on this. Not a technical problem, but it's real. Every bug I hit, I hit alone. There's no one to rubber duck with at 2am when the wgpu render pass is producing artifacts I don't understand. I got good at reading spec documents and graphics debugging tools.
What Actually Worked
The rendering approach with wgpu turned out to be the right call. Once I had the pipeline working, adding effects like zoom, cursor highlight, and background rendering was additive rather than a constant fight with the existing architecture.
The PipeWire integration is solid. Using the native Linux AV stack instead of trying to capture frames through X11 hacks means the capture quality is good and the approach is forward-compatible as more distros move fully to Wayland.
Building in public on X helped me stay accountable. Posting daily recordings made with Screenix, of Screenix being built, was a neat loop that also forced me to actually use the product every day.
Where It's Going
Current focus is export speed and picture-in-picture. After that I want to improve the cursor smoothing algorithm and add support for non-GNOME compositors.
If you're building something on Linux and struggling with Wayland capture, PipeWire integration, or wgpu rendering, feel free to reach out. And if you're on Linux and need a screen recorder that actually looks good, that's what Screenix is for.
Still building.
Top comments (0)