Measure, don’t assume: render cost and iPhone memory

In a video generation project, assumptions are expensive. You believe an effect is free, a layer is light, a fix worked; then you render, you measure, and the number says something else. This article collects the real measurements from MotionMaker, the ones that changed our decisions. None of them is an estimate: they were taken on the engine in production.

Render cost: what a film weighs

A 17-second film at 30 frames per second has 516 frames. Rendering one on the server was measured at about 10 minutes 30 seconds with a concurrency of 2, meaning two frames computed at once. That figure is the yardstick: any change to the engine is judged against it.

Why 2 and not more? The render engine’s default is 4, and at 4 it saturates all eight cores of the machine. The machine is shared with other sites, and saturating the processor chokes them. Concurrency is therefore capped at 2, and the render queue replaces pending renders for the same target instead of stacking them up. A waiting request is superseded by the newest one rather than added to the pile.

Full-screen grain: 54% of the total time

Grain is a classic: a noise texture gives a film some material and takes the edge off digital smoothness. Applying it to the whole frame was tempting. The measurement showed that full-screen grain had cost 54% of the total render time. More than half the time went on a single texture.

That lesson set a rule: any new full-frame pass (blur, grain, filter) has to be measured before it is kept. Not after, and not roughly: before. A pass applied to every frame multiplies its cost by the number of frames, and that cost adds to every other pass.

Depth of field and camera transitions: +15%

Two additions improved the quality of movement: depth of field (a lens keeps only one plane sharp at a time, and rendering everything sharp at every depth makes you “feel the layers”) and transitions designed as camera moves, whip-pans with a trail or push-throughs with depth blur, never plain slides. Measured together, they added about 15% to render time.

A cost of that size can be debated with a number on the table, which would not have been possible without measuring: that is the whole point of measuring before an effect is kept. For what those movements bring on the craft side, read anticipation and overlap in motion design and easing curves explained.

When the render overturns the hypothesis

Several hypotheses were settled by a render, not by discussion: texture anisotropy versus z-fighting (two surfaces at the same spot fighting for the pixel) for an image defect, color grading versus grain for render cost. In the second case it was the grain that weighed 54%. Neither question could be settled by rereading the code.

So the method became a reflex: render a single still with the engine’s still-image command, then build contact sheets with ffmpeg to compare variants side by side. Check by rendering, not by rereading.

Memory on iPhone: a tab that gets killed

The film preview plays in the visitor’s browser, mobile included. iOS Safari kills a tab that goes beyond roughly 1 to 1.5 GB of memory. A preview that looks right but leaks memory is a broken preview. We measured three causes, all invisible when reading the code.

Cause 1: a rotated, rounded, bordered element that moves

An element that was rotated, had rounded corners and a border, and changed position on every frame leaked graphics memory up to 5 GB in 20 seconds. It was the shot we call layered depth. The fix is one line: give it its own compositing layer with the will-change: transform property.

Cause 2: the composition rasterized at screen density

The composition is 1080 by 1920 pixels. On a phone screen it is rasterized at the screen’s density, three times over. Shrinking it visually with a transform is not enough: the browser still computes the large image. The mobile preview is therefore computed smaller, using the zoom property, instead of only being scaled down afterwards.

Cause 3: expensive effects, switched off on mobile

Blurs, glows, glass, grain, color grading and WebGL are turned off on mobile, family by family. The MP4 rendered on the server is never affected: the file you download keeps every effect, and only the in-browser preview is lightened.

How memory is tested

Looking at the screen is not enough: the display can be perfect while the process swells. The test uses Playwright with WebKit and an iPhone 13 profile. It replays a recorded response so no new generation is launched, samples the browser process’s resident memory, and caps consumption at 2 GB, because the server’s memory guard would otherwise kill other processes on the shared machine. A new shot type has to pass this test before it ships.

What this means for the films you create

• Predictable rendering: a film takes minutes, and a new feature does not double that without anyone having measured it.
• A preview that holds up on a phone: it is lighter, but the MP4 export keeps every effect.
• Effects that justify themselves: depth of field is there because it makes the image more believable, not because it is possible.

The same principles apply to a brand video meant for social feeds: see the 9:16 vertical video guide. And for the whole flow: how a website becomes a video. For the other half of the engine’s reliability, read same seed, same video, frame for frame.