To clarify, Cap uses 440 MB of memory when actively playing back a video in the editor (1440p, M4 Max).
When idle with just the main window open, it uses 68 MB of memory and 0.00% CPU 🫡
Cap v0.6.1 is here.
Our engine was always Rust. Now the UI is too, rebuilt on GPUI with no web view. It's much faster.
Memory: 3.7 GB → 440 MB
CPU: 77% → 18%
Exports: up to 5x faster
180+ fixes and improvements from 41 contributors.
To clarify, Cap uses 440 MB of memory when actively playing back a video in the editor (1440p, M4 Max).
When idle with just the main window open, it uses 68 MB of memory and 0.00% CPU 🫡
To clarify, Cap uses 440 MB of memory when actively playing back a video in the editor (1440p, M4 Max).
When idle with just the main window open, it uses 68 MB of memory and 0.00% CPU 🫡
A huge thank you to all 41 contributors who helped make this release happen 💙
Cap v0.6.1 is available now on macOS, Windows and Linux.
Download at https://t.co/0jjEiiONJ9, or update right from the app.
3 for 3 on @cap PRs ✅
Faster video imports. A missing-frame bug fixed. Thumbnails up to 4.3x faster with byte-identical output.
Every one shipped with benchmarks and tests.
More coming, i'm gonna need a Sponsor @cap
https://t.co/RfGUfJf63P
@Cap is really amazing. It's open-source, which is cool. It also just WORKS, which is especially nice on Linux where so many of the alternatives I tried are trash.
https://t.co/YTkcIgrOpF
11 PRs merged into @cap so far, so obviously I (cough my friend opus 5.5 cough) made a video about it instead of touching grass
The cursor recorder was hashing the exact same cursor image every single tick, even when nothing changed. Basically checking your pocket for your keys over and over while they're in your hand. With a big cursor that was 5,204µs a tick, now it's 538µs
Finding your mic for the recording hotkey took 280ms. Now it's 0.32ms
The mic meter was waking up the main thread 93.8 times a second. Now it's 7.2, and 0 when you're silent - which is more than anyone can say about me
Timeline repaints with 120 clips went from 2,178µs to 96µs
And one of them just fixes the lint that turned main's CI red.
Massive cheers to @richiemcilroy for reviewing and merging all of these 🫡
(I forgot to specify that I wanted a 16:9 video not 9:16 - I need to save the extra tokens for more PRs)
It’s never been easier to ship code, but testing has still been a massive bottleneck for us… so I decided to change that 🫡
With @Cap, we’re currently making a full transition to GPUI, and a screen recorder is a strange thing to test reliably, because you can export a perfectly playable video that has the wrong frames in it. Everything appears to work until you look closer!
I don’t want to ship slop, and any regressions are my worst nightmare. The faster we’re shipping code (and generously from contributors!) the more time I find myself spending trying to 100% prove that we haven’t broken something
So I’ve spent the last couple of days building an automated testing harness for Cap… 🥁
It runs our actual media code through repeatable scenarios whenever a relevant PR changes it and runs simultaneously across macOS, Windows and Linux. Also made it so that a draft gets a smaller suite so feedback comes back quicker (this is great for agents!)
The interesting part though is how we know whether the video is correct…
To do this, we generate test videos with an ID encoded into every frame, alongside audio markers placed at exact moments. These are our video fixtures. When we put one through Cap’s exporter, we can decode the result and check which frames actually made it through
So a cut would change which frame should appear next, or maybe a speed change alters when it should appear. We calculate that independently of Cap’s implementation, so the test has something to check the output against
For example, if frame 125 appears where frame 126 should be, we will know. We don’t need someone to sit there watching for it!
Performance gets measured too. The PR and its merge base are built on the same machine, then benchmarked in alternating runs after warming up. That gives us a comparison of CPU time before and after the change, while reducing the noise you’d get from comparing unrelated CI runs
We’ve moved most of this onto @useblacksmith . One Windows test batch went from 9m 52s on GitHub-hosted runners to 2m 59s, about 3.3x faster (!!) Another went from 5m 08s to 45s. Nearly 7x faster for that test step (!!!)
What I hadn’t quite expected though was how much we’d fix while building the actual harness itself
In one crash recovery test, the footage lost went from 11.03 seconds to 1.03 seconds. We also fixed a decoder bug that could show a frame from 89 frames earlier after seeking, without meaningfully increasing CPU usage
There’s something almost self healing about having this in a loop. We get a reproducible failure, fix the cause, and the test stays behind to catch it if it ever comes back. Each fix leaves us less dependent on remembering everything that’s gone wrong before
I think now that we have this in place, the logical next step is to scale it up and run performance/regression testing autonomously from things like Sentry logs and user feedback. Definitely going to commit a decent amount of $ to it. I probably need at least another 4x Claude subs!
Really excited to ship the improvements we’ve already made just from building this. With the harness mostly in place, I can move much faster on my own changes and contributor PRs. Being able to make that progress without the constant worry of breaking someone’s recording feels pretty fucking good I can’t lie 🤩
Got my first GitHub sponsor 🎉
Took up @cap's challenge, made video imports in their new GPUI app ~1.9x faster, and the PR got merged.
1080p60: 62s → 33s
4K30: 82s → 43s
https://t.co/EhRZ6vq7tV
Thank you @richiemcilroy
Just got my first ever GitHub sponsor - and it's from @cap!
I've been using Cap for ages and genuinely love it, so getting sponsored to make it faster is kinda crazy. 11 PRs in, 5 merged, not stopping now :D
Massive thanks @richiemcilroy 🫡
How it feels to be an open source app and you call for reinforcements (PR's) from the community
We've now already shipped some insane performance improvements and bug fixes from people!
Cap v0.6.1 is going to be spectacular as we migrate to GPUI 🫡
Proposition: you create a PR in Cap’s repo with a performance improvement. Can be for the recording engine, export engine, playback, whatever. It should be a demonstrable performance increase with benchmarks. Specifically for the GPUI app.
In return, we’ll sponsor your GitHub 🫡
Proposition: you create a PR in Cap’s repo with a performance improvement. Can be for the recording engine, export engine, playback, whatever. It should be a demonstrable performance increase with benchmarks. Specifically for the GPUI app.
In return, we’ll sponsor your GitHub 🫡