fframes: Rust and SVG video rendering on the GPU, designed for coding agents

Each frame is an SVG tree: the render_frame model

fframes defines video as a Rust program. Each frame of the video is an SVG tree returned by a render_frame function, and the fframes runtime calls that function for every frame during rendering. The svgr! macro inside render_frame lets you embed Rust expressions into SVG markup, so animation values, colors and text content come from Rust code rather than keyframe editors.

The hello-world example in examples/hello-world/src/hello_world.rs shows the structure. A struct implements the Video trait, which sets FPS, WIDTH and HEIGHT as constants and requires a render_frame method that returns fframes::Svgr. From the README:

impl Video for HelloWorldVideo<'_> {
    const FPS: usize = 30;
    const WIDTH: usize = 1920;
    const HEIGHT: usize = 1080;
}

With those constants set, the render_frame body animates a rectangle along a path defined by the fframes::timeline! macro, with frame.index and frame.seconds() available as values inside the SVG expressions. The frame.animate() call takes a timeline specification that defines where a property should be at each time point with a named Easing.

This model means the entire video is a Rust crate. Compilation checks the animation logic at build time, not at render time.

Skia on Metal and Vulkan: why the GPU backend is about 10x faster than CPU

Four design choices drive fframes rendering speed. The Skia backend draws frames on the GPU using Metal on macOS and Vulkan on Linux and Windows. The README states this runs about 10x faster than the built-in CPU backend, which is what software renderers use by default.

Static markup caching is the second factor. Parts of a frame that contain no Rust expressions (no {expressions}) are hashed at compile time and reused across frames by both the CPU and GPU renderers. A frame with a static background and only a moving element does not recompute the background on every frame.

Third, fframes links ffmpeg's libav libraries directly rather than calling a separate ffmpeg process. Removing that subprocess boundary avoids repeated process startup overhead for encoding.

Fourth, SkSL and GLSL shaders can run as layers. The README explicitly supports pasted Shadertoy GLSL as a layer of any frame, so GPU-native effects that SVG cannot express are not blocked.

A data point from the README: a 128-second video, the fframes-intro example, rendered in 36 seconds. That project was built in 48 minutes using the agent skill.

Starting with the agent skill: npx skills add and then describe the video

The documented starting point for new users is the agent skill, not a manual project setup. Install it once with:

npx skills add https://fframes.studio

After that, describe the video to your agent the way you would brief a motion designer. The skill handles the rest: installing fframes, creating the project, designing the motion, placing the sound and checking the result before handing it to you. The README frames the explicit, verbose API as something coding agents handle better than humans, which is why fframes shipped the agent integration before a simplified human API.

For developers building directly in Rust, fframes is published on crates.io. Once a project exists, every command runs as:

cargo run --release -- <command>

For a first check before rendering the full video, inspect flags problems without rendering pixels:

cargo run --release -- inspect

inspect reports missing fonts or images, text cut off by the canvas, invalid SVG and panics, each with its time and scene. Exit code 2 means errors were found. Running inspect before render catches problems in seconds rather than minutes.

What inspect, strip, onion and snapshot give a coding agent working without eyes

A coding agent cannot watch a video or hear audio. fframes provides a set of commands that turn video content into formats an agent can read and reason about.

inspect runs frame analysis without rendering pixels and exits with code 2 on errors. strip creates a contact sheet of evenly spaced frames as a single labelled PNG:

cargo run --release -- strip <scene> -n 12

onion blends multiple frames together to show a movement's path and easing in one image. snapshot compares the current render against approved PNGs and writes .diff.png files marking what changed. audio analyze reports loudness in LUFS, true peak, clipping and silence, and can write a waveform PNG with scene lines and cue tick marks using --waveform w.png.

The timeline command lists every scene with its frame and second ranges, and every audio track with its mix settings. All commands accept --json to make the output parseable by the agent.

That combination is the core of the agent feedback loop: inspect to catch structural problems, strip to review motion thumbnails, snapshot to detect regression, audio analyze to verify levels, and render --draft to encode one scene at half size in about a second for a quick sanity check.

The verbose API and why it stayed unreleased for years

fframes is explicit about the design philosophy behind its API. The README states the API is explicit and verbose, and links to a note from the author explaining that this is why it stayed unreleased for years. Writing explicit, verbose code is exactly what a coding agent with the right skill is good at, and the README frames the agent skill as the solution to the mismatch between the API's verbosity and what a human author wants to write.

For engineers writing fframes code by hand, that verbosity has real costs. Animating a single rectangle across a timeline requires specifying every keyframe with explicit Transform values and Easing names, as the hello-world example shows. A motion designer accustomed to visual keyframe editors will not find a natural workflow here.

The workspace in Cargo.toml contains 15 examples covering podcast, tiktok, marketing, motion-graphics, shaders, signal-lab and others. Those exist as reference material rather than library features, so understanding what fframes can do requires reading example code rather than a feature list.

Remotion as the JavaScript alternative: same paradigm, different runtime

The project workspace contains render-bench/vs-remotion, which benchmarks fframes against Remotion, a React-based video rendering framework. Both treat video as code: Remotion uses React components and JavaScript or TypeScript, while fframes uses Rust functions and SVG.

The practical difference is the target developer. Remotion is the natural choice for front-end teams already writing React, since components, hooks and JavaScript tooling translate directly into video development. fframes targets developers in the Rust ecosystem or those using coding agents to produce videos without caring about the implementation language.

Remotion has a larger community, longer release history and a hosted rendering service. fframes has no hosted rendering; render runs locally. The GPU speed advantage that fframes documents may or may not matter depending on whether render time is a bottleneck in a given project.

MIT licence, 3 releases in 5 days around v1.0.3 through v1.2.0, and the workspace layout

LICENSE.txt in the repository root confirms the MIT licence. The fframes crate is published on crates.io with a docs.rs page for the API reference.

Release pace was rapid around the v1.0 launch: v1.0.3 on 2026-09-29, v1.1.0 on 2026-09-30 and v1.2.0 on 2026-10-03 represent 3 releases in 5 days. The last push to the repository was on 2026-10-06. The project is at version 1.x, which indicates the API is not considered stable across major versions in the way a 2.x or higher project would be.

The workspace is a Rust monorepo with members including fframes, fframes-skia-renderer, fframes-native-player, fframes-media, fframes-editor-controller and cargo-fframes, alongside the examples and render-bench. The repository also includes JavaScript tooling: [email protected] manages the editor frontend (fframes-editor), and the justfile shows that a full developer setup requires ffmpeg, rustc, pnpm and wasm-pack working together. That dependency stack is a real setup cost for contributors who want to modify the editor.

Editorial conclusion

fframes suits Rust developers building data-driven or generative videos where the content comes from code rather than a timeline editor, and teams using coding agents to produce motion graphics from a text description. Skip it if your team works in JavaScript and React, where Remotion covers the same paradigm with a larger ecosystem. Before committing to fframes, clone examples/hello-world, confirm your GPU backend (Metal on macOS, Vulkan on Linux or Windows) is working, and run cargo run --release -- inspect to see whether the dependency chain builds cleanly on your machine.

Frequently asked questions

Official sources

1. dmtrKovalenko/fframes on GitHub
2. License: MIT
3. Project website
4. README
5. Releases