Currently, when rendering an animation, Blender first renders a frame, then
writes it to disk, and then continues with the next frame.
In some cases, this can introduce a considerable slowdown:
- When using Eevee
- When rendering very simple scenes with Cycles
- When using high compression settings
- When using slow storage (e.g. writing huge EXRs to a network share)
Since the frame writing is mostly singlethreaded and doesn't depend on scene
state, it can be executed in the background while the next frame is already
being rendered.
The current code is designed to only use one background thread, meaning that
it waits for frame N to be written before it writes frame N+1.
Using a deeper queue could provide even more speedup if rendering is faster
than saving, but that's probably fairly rare and not possible with movie
output, so the single thread is easier to implement for now.
The three downsides of this currently are:
- A copy of the old Render Result has to be kept in memory, increasing RAM usage.
- Console messages about the frame writing are mixed into the usual rendering logging.
- It's unclear how to properly handle the render_write callback.
For these reasons and because it's hard to test all the special cases, the option is
currently controlled by a User Preference that defaults to off (similar to other
options that have an impact on RAM usage). In the future, we could turn this on by
default.