Shader transitions are much slower than hard cuts despite workers

[markwitt1]

Shader transitions appear to force a much slower render path where worker parallelism does not materially help.

Benchmark, same composition and render settings:

• 854x480
• 30fps
• 28.0s
• 840 frames
• standard quality
• 6 workers
• GPU/browser GPU enabled

Results:

• With 14 shader transitions at 0.3s each: 2m 15.0s
• Same timeline with hard cuts instead of shader transitions: 13.9s

That is about 9.7x slower.

Expected: short shader transitions should add some cost, but should not make the whole render nearly 10x slower or bypass worker scaling.

Likely cause: the shader-transition render path appears to use a sequential layered-composite loop across frames, while the normal path distributes frame capture across workers.

Possible fixes:

• Parallelize the shader/layered-composite path by frame range.
• Avoid using the layered compositor for frames outside active transitions.
• Consider a GPU-backed transition compositor for the shader blend itself.

[vanceingalls]

Thanks Mark — your analysis in this issue was spot on and directly shaped the fixes.

Root cause

Shader transitions used a Node-side layered compositing pipeline: two transparent screenshots per transition frame, pixel transfer to Node, color space conversion, and CPU shader blending in a worker_threads pool. At higher worker counts, coordination overhead between Chrome instances and the blend pool made renders slower — the opposite of expected behavior.

How your suggestions mapped to what we built

"Avoid using the layered compositor for frames outside active transitions" — This was the first incremental win. We introduced a hybrid capture path where non-transition frames use the fast parallel screenshot path while only transition frames go through the layered pipeline. This helped compositions where transitions are a small fraction of total frames, but didn't solve the core problem for transition-heavy compositions.

"Consider a GPU-backed transition compositor for the shader blend itself" — This became the main fix. We moved the entire shader blend into Chrome's WebGL via a page-side compositor using drawElementImage. The GLSL fragment shaders now run on the GPU where they belong, instead of being emulated in Node's CPU worker_threads. The engine takes one opaque RGB screenshot per frame — transition or not — which is why worker scaling now works.

Additionally:

• Video support: a three-phase capture protocol (inject video frames → clone scenes → shader composite) so videos play through shader transitions on the fast path instead of freezing
• Runtime video discovery: the engine seeks the GSAP timeline during the probe stage to find when each video's scene is visible, auto-setting correct extraction timing — no data-start/data-end attributes needed on <video> elements

Results

Your benchmark composition (854x480, 30fps, 28s, 14 transitions, 6 workers):

Workers	Before	After	Speedup
1	135s	20s	6.8x
6	139s (slower than 1!)	7.0s	19.9x

Shader transitions now scale linearly with workers.

[markwitt1]

Sounds great! Will try it out very soon. Side note: I see some recent work on AWS Lambda distributed rendering. afaik AWS Lambda does not support GPUs, as opposed to Google Cloud Run Functions. Any plans to support that as well / do a more provider-agnostic solution?

[jrusso1020]

@markwitt1 thanks for the question!

Our current focus is lambda as that's been a request from users coming from Remotion who are familiar with their lambda distributed rendering solutions

The implementation of distributed rendering is in general provider agnostic and we are are also migrating our current internal k8s based rendering solution to use it as well. So the solution itself is already provider agnostic, we are just trying to have a simple lambda based solution as well out of the box

We could look at other providers in the future but also happy to see contributions here externally if people are interested

You can feel free to open up a new issue for the Goole Cloud Run Functions provider support for us to track interest