The renderer we had to switch off
Note 01 ended with a renderer that drew our videos without a browser, 2.4 times faster. It went live on 31 October, and we switched it off the same evening: one failing export could take the server down with it. Exports went back to a browser.
That left two problems. The first was the fault, which is fixed and is not the subject here. The second was harder. Our server is small and shares its cores with everything else we run. Even a renderer twice as fast would have choked it. So the question changed from "how do we draw faster than a browser" to "how little work can a frame be, and where should that work happen".
Where a frame's time really goes
We timed every drawing step in a frame and sorted the steps by what they were for.
The things a viewer looks at are almost free. A line of text takes 16 millionths of a second. A shape, about the same. The time goes to what surrounds them: the glow around a drawing, the shadow under a caption, the soft background behind everything. The shadow under one line of text cost 120 times the text.
That was the finding. A video is read through its words and its drawings, and almost none of the cost is there.
What we are not going to describe
We rebuilt how our renderer makes the soft parts. This note does not say how. It took us two tries and a server outage to get here, and it is the part of this work that is ours.
What we can show is what came out, and how we made sure the picture did not change.
The picture had to stay the same
"Faster, with no loss of quality" needs a referee. Before changing anything we had a browser draw 485 frames of 23 videos, and compared ours with them after every step. A step that moved a frame away from the browser's was thrown out.
The first comparison was a surprise. Some of our frames were simply wrong.
Figure 2One frame, three renderers
A The browser
B Ours, before
C Ours, nowWe found eleven differences that had nothing to do with speed: a title that wrapped where the browser's did not, a missing logo, a dropped space between two pieces of text, a language's name in its own script that came out as empty boxes.
Figure 3A glow that was a third as strong as it should be
A The browser
B Ours, before
C Ours, nowTwo of them had been hiding inside every glow we drew. Nobody had seen them, because nobody had put the two frames next to each other.
Figure 4Closer to the browser, case by case
Data
| Before | Now | |
|---|---|---|
| Brand film | 26.5 | 36.0 |
| Our own promo | 26.5 | 32.3 |
| GTA style | 29.1 | 33.7 |
| Urdu, with maps | 31.9 | 35.6 |
| Chalk | 31.2 | 33.4 |
| Neon, the default | 31.8 | 33.3 |
So the work on speed left the renderer more correct than it found it.
What came out
Figure 5The work to draw one frame, look by look
Data
| Before | Now | |
|---|---|---|
| Chalk | 131 | 17 |
| GTA style | 122 | 65 |
| Brand film | 87 | 42 |
| Cinema, with film grain | 74 | 19 |
| Story in pictures | 71 | 14 |
| Urdu, with maps | 66 | 42 |
| Sketch | 46 | 14 |
| Neon, the default | 36 | 21 |
| Pop | 22 | 19 |
| Clean | 22 | 16 |
Drawing a frame now takes about half the work on average, and far less on some looks: chalk went from 131 ms a frame to 17.
A renderer that needs no browser can also leave our server. The drawing now happens in the cloud, and our server no longer draws a single frame.
Figure 6Drawing the same 60-second video in the cloud
Data
| Seconds | |
|---|---|
| Through a browser | 58.7 s |
| Our renderer | 11.5 s |
Figure 7What a minute of video costs to draw
Data
| US cents a minute of video | |
|---|---|
| Through a browser | 2.85¢ |
| Our renderer | 0.75¢ |
The same 60-second video that takes 58.7 s to draw through a browser takes 11.5 s, for 0.75 cents instead of 2.85. On a laptop, with no cloud at all, the same export went from 63 s to 25 s.
The first real export failed
We switched it on for our own accounts first, on the evening of 13 November. Forty-two videos were exported on the site that night. One of them was ours and took the new path.
It failed. The old path took over and finished the video, so nothing was lost but time.
The reason was dull. Right after an update, the cloud machines all ask our server for the same file in the same second, and the server answered some of them before the file was whole. Our own test had passed because we had fetched that file once, by hand, before running it. The test never saw what a real first export sees.
We fixed both ends: the server no longer hands out a file it is still writing, and a machine that receives a broken one asks again. Then we tested the way it is really used: cold, first thing after an update, with nothing warmed up. It held.
The lesson is older than this renderer. A test you prepared by hand tells you about the test.
Where it stands
It has been on for every account since 14 November.
Figure 8What a person waits for a one-minute explainer
Data
| Seconds | |
|---|---|
| Through a browser | 55 s |
| Our renderer | 32 s |
A one-minute explainer is ready in about half a minute, where it took about 55 seconds. That is less than the 5× in the drawing, because the sound, the joining and the finishing pass take what they took before. Those are next.
Stories told in pictures gained little, and 3D simulations are still drawn by a browser. Simulations did get faster in the same week, for a plainer reason: they are now drawn by many machines at once instead of one. That needed no research, only a larger allowance from the cloud.