I don't know why this wasn't written to do this before, perhaps I thought waiting for the thread would achieve this goal. Anyway, in my testing, this ensures render jobs are complete before the task returns.
Fixes#1899Fixes#1900
I'll be honest, this probably makes no noticeable difference at all. It should be faster and more efficient, but whether that translates into any tangible improvement is yet to be seen.
Project items are now represented directly in nodes opening up more versatility and possibilities. This is the first iteration of this and will be buggy. Need to test thoroughly.
The macro defined namespaces confused the hell out of lupdate and more or less broke translations permanently. Looks like the only way we can do it is to have a hardcoded namespace, which goes against my instinct, but honestly how likely is it that we'll change the namespace anyway (I guess forks might want to do it, but that's their problem ;) )
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.
These are two changes that speed up when frames start getting rendered
and processed (particularly for larger scale projects):
* Sorting of time beforehand was done to optimize decoding but is actually
unnecessary since the frames are already sequential when they're retrieved
from the range. As long as we maintain that order, no sorting is required.
This speeds up caching IMMENSELY.
* Evaluate hashes concurrently while retrieving frames. Before, this was
done before any rendering and could therefore delay rendering by several
seconds. Doing them concurrently means frames start rendering almost
immediately and further hashes can be analyzed while we wait for frames to
finish rendering.
itsmattkc