I was under the impression Q_DISABLE_COPY_MOVE was a much older function than
it is. Since we historically target 5.6 and these functions are small
convenience functions, I just implemented them in the actual codebase.
Previous iteration had params attached to the backend and the params couldn't
change without being destroyed and re-instantiated. This is not necessary in
this iteration so doing so only wastes resources.
Since we're now working with a separate proxy copy of the original node graph,
if the user changes a parameter in one of those nodes (triggering an
InvalidateCache signal), the values in our copied graph need to be updated
with these new values too.
A signal emitted and received in the same thread will call other functions
before returning to the one that emitted the signal. If these other functions
try to lock a mutex while a mutex is already locked by the emitting function,
we get stuck in a deadlock. These changes ensure that a signal is never emitted
by any function until all the nodes locked by it are unlocked.
Previous iterations would use mutexes to prevent changing of the graph
mid-render, however several user actions would need to capture these mutexes
causing the main thread to hang until the current render job (frame/range of
samples) was complete. We now copy the nodes necessary as part of the "compile"
process so that the main thread shouldn't need nearly as much blocking while
caching occurs.
Useful for detecting when a graph needs recompiling, in tandem with the
"InvalidateCache()" signal when necessary, this signal ripples through the
nodes when any of the connections change which will likely need handling by
the renderer.
Sometimes we'll be copying nodes without wanting to copy their connections,
since we'll want to connect them to equivalent copies rather than connecting
them to the same nodes the originals were connected to. We now have an extra
parameter to distinguish such operations.
If the bytes retrieved is less than the bytes we expected for the time period
we're rendering, we fill the remainder with silence. Fixes segfault trying to
copy bytes that aren't actually allocated.
Foundation for a fairly simple but likely essential autorecovery process.
Basically the same as what it was in 0.1.x but with a huge improvement: custom
autorecovery intervals. Ironically there isn't any "saving" to be done
just yet, but when there is, this infrastructure will be ready for it.
Updating values rapidly would cause strange jitters as a
byproduct of the viewer trying to update from the renderer while
it was still working. Rather than the viewer trying to access the
the renderer, we now send textures in the initial update signal
to keep everything synchronized.
I was looking for a way to update the length value automatically with signals
and slots (rather than just checking every time the viewer time changes). This
should do the trick.
Both audio and video renderers were working off the same invalidation signal
(i.e. changing audio would also trigger a re-render of the video). This is
obviously suboptimal and now they are separate.
Since we're storing media frames too with no disk space management
at the moment, we'll remove the mediaindex folder too on close
just for this testing period
Many changes were made throughout the codebase to support audio, these are
most of the small changes necessary.
The audio support still is not perfect. I still need to write in resampling
support. After that it should work correctly with all audio types.
Previously, the viewer could be set up with a custom PCM file to test playback
and scrubbing. Now these functions are connected to the audio renderer to
work within the render system.
itsmattkc