For seven years I ran the engineering side of VSporte, a company that builds software for sports broadcasting. Everything described here is VSporte product development, done by the company's engineering teams. My part was the architecture and the calls about where the work went next. Our on-air graphics started where most production rooms start, as a folder of vMix titles files, and over a few years they left vMix completely. vMix still does the final mix. The graphics are not inside it. This is the part of the story that shipped. Three steps, and the useful thing about them is not where we ended up, it is that every fix created the next bottleneck. If you work in broadcast you will recognise at least one of them, probably the first. Step zero: vMix and a folder of gtzip files The setup we started from is the one standing in most production rooms. vMix on a workstation, and the graphics living as gtzip files, which is vMix's proprietary titles format. The operator loads the pack and configures the titles inside vMix by hand. Presets exist and they make a repeat setup cheaper than the first one, but the data behind every graphic still has to be carried through, match after match. The obvious objection is that vMix has an answer for this, and it does. Data Sources will drive titles from Google Sheets, Excel, CSV or XML, and the standard forum advice to anyone staring at a pile of near identical graphics is exactly that: one title instance plus a spreadsheet. It is good advice and much of the industry runs on it. It also solves a narrower problem than ours. A spreadsheet collapses the variants of one graphic. A client package is not variants of one graphic, it is twenty to fifty different elements, scoreboard, lower thirds, line ups, season statistics, each its own template. The spreadsheet does not reduce that count, it does not make a template testable, and it does not change who opens the editor when a client wants one to behave differently. You can host vMix itself in the cloud, and people do. It moves the same workstation into a data center and changes nothing about how graphics are made, loaded or driven. The workflow was the problem, and the workflow stays. Step one: the overlay becomes a web page The first real change was building our own graphics control platform and turning the on-air overlay into a web page, fed into vMix as an input layer. vMix still does the final mix. The graphics no longer live inside it. Two consequences, and if you have run vMix with a large titles pack, the first one needs no explanation. The memory load on vMix became constant. A gtzip pack loads into vMix and the footprint grows with every template you add, and packs grow, because clients keep asking for one more graphic. You do not have to take my word for the ceiling, because the vendor documents it. vMix's own performance notes put an average HD title template at 100 to 200 MB of graphics memory and recommend no more than twenty templates open in a preset at once. A client package in our world was twenty to fifty templates. We were starting at the number where the vendor says stop. The same page carries a number that mattered more to us than the template count did. A five second full frame image sequence at 1080p60 needs nearly 2.5 GB of graphics memory, because every frame of it is a bitmap sitting in VRAM. One animated intro can therefore cost more than a dozen static templates, and animated intros are not an exotic request, they are the first thing a client asks for. The vendor's own advice is to shrink the sequence to the exact rectangle it will occupy, which works and which is also an admission of what the format costs. With the overlay as a single web input, the footprint stopped depending on the size of the package. A fixed cost instead of one that grows with every element in the pack. The graphics became testable. A web page is checked with ordinary web testing practices, the same ones every frontend team already runs. In broadcast graphics that is genuinely rare. A proprietary titles format gives you no handle to test against, so graphics get verified the traditional way, by a person looking at an output and hoping the edge cases show up before air. There was a third effect on the operators. The data behind the graphics moved into the platform, structured and reusable, so nobody was configuring titles inside gtzip files anymore. Teams, scores, clocks come from the system, and the overlay binds to them. And here is the problem this step created. Every graphic now had to be built as a web layout, by a developer, in code. Step two: the bottleneck moves Porting one element from gtzip into a hand-coded web layout with animations took on average about a day and a half of developer time. A client's package is twenty to fifty of them. Multiply those and you get the real cost of every new client. But the worst part was not the throughput, it was the predictability. A six month plan collapsed the day a new client signed, because their graphics package jumped the queue and ate the developers who were supposed to be building features. We were not short of compute or short of ideas. We were short of a way to promise dates, and graphics production was the reason. Step three: Rive takes the layout work We moved graphics creation to Rive. A designer draws the graphic and wires up its state machine in the editor. The developer only maps data onto the view model, score to this field, team name to that one. One graphic went from about a day and a half of developer layout to about half a day of design work. Throughput settled at four to eight a day. And because it is design work now, it scales with outsourced designers, who cost two to three times less than developers. The bottleneck that had been breaking our plans was gone, and the developers went back to the product. It did not land cleanly. Our first integration of Rive on the web side was too greedy, and beta testing showed it adding thirty to forty milliseconds on top of what we already paid. We caught it on the bench, fixed it, and the graphics layer settled at forty to fifty milliseconds in total. That is one input carrying the whole package, not one source carrying a single lower third. It also closed the memory question from step one, though not in the way a tool comparison would suggest. Rive holds raster images perfectly well, and its own documentation warns that large ones eat device memory. Put that same five second sequence into Rive as frames and you pay again: in our practice around 300 to 500 MB at 1080p, better than 2.5 GB thanks to WebP compression, but the same order of problem. What changed was the default. Authoring in Rive means drawing the motion instead of recording it, so the animation becomes shapes, keyframes and a state machine, a few hundred kilobytes, and its footprint stops growing with duration or frame rate. The variable was never the tool. It was whether the animation is stored or computed. This step created its own consequence, although it took a while to see it as one. A graphic was now a file with a state machine, driven by plain data. It did not need a browser to render. And it had never needed a GPU, we had just always rendered it through tools that came with one attached. The part worth taking away Look at what each step actually did. The web overlay took the graphics out of vMix's memory and made them testable, and in exchange it created a layout bottleneck. Rive removed the layout bottleneck, and quietly turned every graphic into a portable file. That last consequence is the one we did not plan for. We changed tools so that designers rather than developers would do the layout. What we got at the end of it was a graphic that no longer needed the tool it was drawn in: a file, a state machine, and some data to bind to it. Which left a question I could not put down. If a graphic does not need a browser to render, and never needed a GPU in the first place, what exactly is the GPU workstation still doing in a rented room next to every parallel broadcast? I went and answered that, and that is the next article. I am Andrei Novikov. I spent seven years running the engineering side of VSporte and I write about backend and realtime architecture. If you are at IBC and doing something adjacent, I am interested in comparing notes.