This mostly builds on the keyframing we already set up for video, but the
audio renderer will now appropriately updated keyframe inputs per sample in
accordance with keyframe values.
Since EmitCachedFrameReady() makes a copy of the texture, we can economize a lot
by re-using the same copied texture for all the times rather than making a
separate copy for each time.
The encoder was moved to its own thread and will transcode the PCM from the
audio renderer into the chosen codec while the video frames are still
received. The implementation isn't perfect and could use some cleaning up, but
it is functional at the moment.
Sending a texture directly from the texture cache is dangerous since once the
reference is relinquished, it could be picked up and used by another thread.
Copying the texture to a separate one takes a little extra time but lets the
viewer remain in control of that texture.
Various backend improvements are included in this commit, mostly for the
benefit of exporting. These include:
- Moving more non-GL code from OpenGL derivatives into base classes
- An "export mode" that changes the cache behavior of video backends
- Using the Viewer's UUID introduced a few commits ago
- No longer hardcoding the pixel format/render mode in the backend (since
they'll inevitably differ when exporting vs previewing)
- Improved signalling for frames that are completed
OCIO config was set on a per-project basis, but we were using a singleton for
the ColorManager that would break if more than one project was ever open.
Now the ColorManager belongs to the Project and is always accessed through the
Project.
This commit adds the background functionality of the render cache invalidating
whenever a footage's color space is changed. This includes when the project's
configuration is changed as well.
Uniform values cannot be set if the shader is not bound, and calling Blit would
release the shader making subsequent iteration count updates not work. This
commit makes sure the shader is bound before trying to do so.
Ultimately it would be nice if nodes could configure this themselves, but
CLAMP_TO_BORDER behavior can be written manually into the shader if that
behavior is desired, whereas CLAMP_TO_EDGE cannot.
Creating and destroying textures is a slow process, particularly when we can
re-use them throughout most of the render chain. We now keep them stored so
they can be re-used which improves performance substantially.
This was many changes that were largely fundamentally related. They included:
- More const modifiers to enforce read only node graphs
- Support for fragment and vertex shaders from the nodes
- Support for node code loaded externally (embedded into the binary)
- Fixed issue preventing two textures from being used in a shader
- Removed several unused functions and cleaned up code
- Fixed video media node misreading its matrix input
Workers run in different threads and the backends can poll whether the worker
is currently busy or not. However the previous iteration has the worker (and an
atomic int) provide the busy state which could easily desync with the main
thread (since all workers run in different threads). By holding the busy states
in the main thread, the main thread will always be able to poll the busy state
accurately.
If the nodes are now stateless, there's nothing stopping the renderer from
rendering multiple frames at once. Earlier since the nodes held some of their
input/output data (and that data could change per frame), it was not possible
to render multiple frames at once without conflicts. Now that the node state is
held in render threads, they can do whatever they want at any time.
If Nodes only have the one output, we don't need to do so much differentiation
between them. Previous iteration used outputs as like a distinct function
within a Node (e.g. length output would return one result, buffer output would
produce a different result - each run different code to produce their results).
Now in this iteration, it's more accurate to say a Node is just one function
(which seems more appropriate for a node system anyway).
Largely conforming renderers to new NodeValue system. Code seems a lot cleaner
this way which is a nice advantage. Likely non-functional as this won't
compile just yet and still needs probably another day or two of testing to get
it back to where it was before.
Old code assumes that a NodeParam's parent will always be a Node. The function
has been separated off and tweaked in the event that this is not the case.
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 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.
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.
Major refactoring work to try sharing as much code as possible between the
video renderers and audio renderers, as well as make them as
platform-independent as possible.
itsmattkc