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.
itsmattkc