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.
I think there was an earlier commit with a similar name but turns out
I'd only done foundational work in that commit and never actually
properly set it up. Of course once I did, there were several issues that
needed fixing to make it work correctly, but now it works as expected.
Heavily optimizes larger projects by allowing cache jobs to only copy
what has changed.
Since auto-cache events start and stop fairly frequently (and are somewhat
heavy to create/destroy), we can save a lot of cycles over time by sharing
the same backend between them all.
Previously, audio was all queued first and would therefore all have to
finish before any video frames could start caching. No longer! Now they're
queued side by side so users won't have to wait for audio to finish before
their cached frames come in.
Removed proxy task and replaced with a true honest-to-god pre-cache for
footage. This footage is pre-cached to a sequence and therefore 100% ready
for use in it once the task is done.
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.
- Replaces QLinkedList with std::list as recommended by Qt docs.
- Replaces QWheelEvent::delta() with QWheelEvent::angleDelta(). This
should also benefit trackpad behavior.
Implemented a smarter auto-cache that's context sensitive. Caching will
automatically pause when playback begins or values are being changed and resume
when inactive.
This dialog caused a bunch of warnings and was unused in the new renderer
system. It may be used again later, so it's just been commented out, but there's
currently no plan to.
Turned the two-step PCM transcode into one step and simplified/removed much of
the unnecessary infrastructure that supported it. This makes the code cleaner
and generally improves the code paths.
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.
itsmattkc