This is needed in cases when using blender camera with different
resolution than original footage. Behaves in the same way as
background picture framing.
Added a framework to run effects in several threads. Port most
of effects to this new framework.
Still some work to be done here (some effects are not so easy to port)
Before this the the whole sequencer cache would be invalidated
when hanging sequence settings.
This was completely annoying because changing color balance
settings would re-load image file for which color balance
is happening on every change,
In fact it's still an issue if color balance is changing for
image strip itself, but if this strip has got effect and
color balance is changing for it file wouldn't be reloaded.
Should give some more realtime update, but it's currently not the
biggest issue - changing color balance settings would imply reloading
of file which is slow. Would be investigated further.
This change shouldn't affect on pre-fetching job which is already
multi-threaded and doing threaded color balance would make things
only worse.
The reason is that the per-node updates used for Reroute node type inheritance are not supposed to be looking at connected nodes, they are purely for "local" updates. For this sort of "global" update which requires depth-first search, the update function on the node tree level must be used instead.
Useful in cases when masking stuff like self-intersecting
ropes. This could probably be smarter option, but can't
currently think about robust approach here.
Enable self-intersection check for preview. In own tests average
time for this operation on mango files was ~0.0015sec, and it was
like 20 splines max which still gives pretty smooth performance
on my core quad machine.
Would think let's check how it works for now, if it'll give some
issues here, would just avoid tessellation on every redraw by
storing tessellation in some cache (probably in mask user).
Another change is related on a way which loop to collapse.
Changed length check with AABB size check. A bit slower but
should be a bit more predictable.
- resolution could become so high that it would wrap around to a negative number, now check for small numbers before doing float division.
- resolution was being calculated in some cases when it already met the clamp value - now this is skipped.
