From: Steinar H. Gunderson <sgunderson@bigfoot.com>
Date: Thu, 13 Jun 2019 20:59:18 +0000 (+0200)
Subject: Rework the chain concept.
X-Git-Tag: 1.9.0~34
X-Git-Url: https://git.sesse.net/?a=commitdiff_plain;h=337e2d06624b4b46eb2e7e5365e2ece219f9f100;hp=337e2d06624b4b46eb2e7e5365e2ece219f9f100;p=nageru

Rework the chain concept.

For complex themes, building the multitude of chains one might need
has become very bothersome, with tricky Lua scripting and non-typesafe
multidimensional tables.

To alleviate this somewhat, we introduce a concept called Scenes.
A Scene is pretty much an EffectChain with a better name and significantly
more functionality. In particular, scenes don't consist of single Effects;
they consist of blocks, which can hold any number of alternatives for
Effects. On finalize, we will instantiate all possible variants of
EffectChains behind-the-scenes, like the Lua code used to have to do itself,
but this is transparent to the theme.

In particular, this means that inputs are much more flexible. Instead of
having to make separate chains for regular inputs, deinterlaced inputs,
video inputs and CEF inputs, you now just make an input, and can connect
any type to it runtime (or “display”, as it's now called). Output is also
flexible; by default, any scene will get both Y'CbCr and RGBA versions
compiled. (In both cases, you can make non-flexible versions to reduce
the number of different instantiations. This can be a good idea in
complex chains.)

This also does away with the concept of the prepare function for a chain;
any effect settings are snapshotted when you return from get_scene() (the new
name for get_chain(), obviously), so you don't need to worry about capturing
anything or get threading issues like you used to.

All existing themes will continue to work unmodified for the time being,
but it is strongly recommended to migrate from EffectChain to Scene.
---