Ideas are easy to have and hard to prove. So the first goal was deliberately small: get layers onto the screen, composed by the GPU, at a steady frame rate. Everything else could wait.
It took six days. Most of the important decisions were made in the first two.
A native core, from the first line
A production tool lives or dies by its render loop. If the core cannot keep a steady 60 frames per second with several layers, effects and outputs, nothing built on top of it matters.
So the core is native: Rust, with a GPU compositor that does the actual work of combining sources, layers and effects. Nothing in the picture path goes through a browser engine. Frames are composed on the GPU and leave the application from the GPU.
By the end of the second day it rendered layers from real sources, with transforms and stacking order. On the third, after a round of performance work, it held 60 fps without drama. That number became a rule rather than a target.
A web interface on top
The interesting choice was the interface.
Desktop production tools usually build their interface with a native UI toolkit. That works, but it boxes you in. Every list, inspector, timeline or custom control has to be built within the limits of that toolkit, and the pool of people, components and ideas around it is small.
Muxivo Studio uses Tauri instead: a native application with a web-based interface. The Rust core does the heavy lifting; the interface is built with web technology.
What that buys:
- Freedom in the interface. Layouts, inspectors, editors and live controls can look and behave exactly the way the workflow needs, without fighting a toolkit.
- The largest UI ecosystem there is. Components, accessibility work, typography, animation and tooling from the web, instead of a framework with a fraction of the options.
- A natural home for HTML graphics later. If the interface already speaks the web, so can the graphics.
The one compromise
There is a cost, and it is worth being precise about it.
The picture lives on the GPU. The interface lives in a webview. Getting a frame from one to the other is not free: it has to be read back, encoded and handed across. That is why the preview inside the interface runs at a lower resolution than the actual output.
That preview is a convenience for designing scenes, not the monitoring path. The real monitoring is native:
- Program, Preview and multiview in their own windows or full screen, drawn directly from the GPU at full quality.
- Outputs fed straight from the compositor, never through the interface.
So the trade-off only touches the in-interface preview. It is the only compromise the architecture had to accept from the start, and it is a limitation of the current generation of the framework rather than a dead end. The next major version of Tauri is expected to add a Chromium-based runtime. When it arrives, we will revisit the in-interface preview and most likely replace the current path with a far more efficient one.
Scenes, and the first rewrite
With layers working, the next steps came quickly: cropping and colour sources, video sources with their own preview, a per-layer preview rendered on the GPU, and scenes.
On day five I threw most of it away.
The first version had proven that the approach worked, but its structure was already fighting the features I knew were coming. A rewrite that early costs a day; a rewrite three months later costs the project. The new structure came with proper saving and loading, scene management, and a clean separation between the sources a show uses and the layers that place them.
By the sixth day there was a real first frame: scenes made of layers, composed on the GPU, saved to a project, rendered at a steady 60 fps.
What comes next
A frame is a start, not a show. The next step was the part that interested me most: effects that belong to layers, and the first move from flat 2D towards real space.
That is the next chapter.