Implements a very basic GLSL deinterlace that simply halves the vertical
resolution and then interpolates between the fields. This can be toggled
on or off.
The reasons for being so basic is:
- Speed, very quick code running in OpenGL
- It would seem the highest quality deinterlacers are temporally based
which doesn't make much sense for the viewer, particularly since we can't
double the frame rate since our timecode is fixed to the frames.
Higher quality interlacing/deinterlacing will be present in the actual
renderer.
Implements the following:
- Sequences have pixel aspect ratios that work in tandem with footage PARs
to render footage correctly. Viewer and export also acknowledge PARs
- Sequences can have interlacing settings. This doesn't do anything yet,
eventually the renderer will need to interlace/deinterlace/reinterlace
appropriately in order to conform all the footage to the sequence. Export
acknowledges interlacing, but this only affects metadata, not the image.
Shifted from CacheTask to functionality built into RenderBackend. It was
a lot easier to control behavior this way without having to juggle a ton
of threads and race conditions.
Could likely be multithreaded further.
Improves stability and cache reliability.
Earlier iterations were prone to skipping necessary signals (usually
leading to some sort of assert fail), particularly when track
optimizations were used. Those optimizations have been moved to the
viewer node so there's a higher degree of control over which signals
get optimized and in which ways.
Ensures their thread gets changed along with the viewer. The project
gets loaded/created in a background thread so the GUI can remain
responsive, and is then moved to the main thread for intended event
handling. However if the caches aren't parented, the hierarchy breaks
and the caches remain in a thread whose event loop is quickly destroyed.
Now that they're parented, events can be properly queued on them once
again.
Addresses scheduling issues where a backend might be closed (or even
destroyed) before it processes a waveform signal from a worker. Requires
extra multithreading code.
Features a lot of timeline-related cache optimizations as well as general
optimizations and improvements in timeline behavior. Should improve
usability significantly.
Rather than plugging a matrix into the video input node, the matrix is now
multiplied by the video input using a math node. This is probably more
sensible from a user perspective.
This also means the renderer is tolerant of texture sizes that are not equal
to the sequence size, however most nodes will downsample the texture to the
sequence size (and if not, it will be downsampled once it is cached). Textures
will still *always* be in reference space and the sequence's format. This seems
like the best compromise between backend and frontend congruity.
A huge optimization that ensures only the parts of a node graph that have
changed get pushed to the renderer. For thread-safety, the node graph is
copied elsewhere so that users can make changes asynchronously and the graph
can update when its threads are ready. Up until now, if an input value changed,
every node's values would be re-copied, or worse, if a connection was changed,
the entire graph would be recopied. This has been negligible in testing since
we've been largely testing with small graphs, but for massive projects, it's
important that this be as optimized as possible.
This required various changes to various parts of the infrastructure (mostly
using paths to finding the "root project" of any given object throughout).
Now theoretically infinite projects can be opened and accounted for at any
given time.
itsmattkc