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.
As opposed to simply leaving all values in the table, nodes can now "take"
values that they use to free up memory (e.g. "taking" input buffers if they're
used to produce an output buffer).
This is a fairly large change, expect regressions.
Due to an oversight, incoming footage frames were NOT converted to the
working pixel format (usually half or float). For most frames, this meant the
OCIO conversion would occur on frames while they were still in their source
format (usually either RGB8 or RGB16). This leads to rounding error
inaccuracies, but even worse GLSL will clamp integer textures to 1.0 potentially
losing a lot of data.
While later nodes would correctly convert to the appropriate format, by then it
would be too late. This commit corrects this issue, converting the frames to
float during the OCIO shader pass.
Several things are accomplished in this commit, including:
- Use OIIO instead of our own functions for pixel format conversions
(cleaner code/less for us to maintain)
- Fold all PixelService functions into the PixelFormat class
(cleaner code)
- Moved OpenGL pixel definitions to OpenGL classes and out of the
global classes.
- Add support for RGB buffers as well as RGBA (optimization)
Fixes a number of playback stuttering and general UI lag issues by setting all
background tasks to IdlePriority rather than LowPriority. While it was assumed
LowPriority tasks would always get scheduled below NormalPriority (e.g. main
thread) tasks, it turns out this is not always the case. If the background tasks
start consuming a lot of CPU cycles, the scheduler may use "dynamic scheduling"
to schedule them above the main thread regardless leading to UI lag. This is
apparently the case for all thread priorities apart from IdlePriority, which
is allegedly a special case where threads are *only* scheduled when other
threads aren't busy ensuring the main thread stays responsive.
context
More intuitive code flow and allows the user to undock the viewer (which
forcibly destroys and recreates the context) and the viewer will handle
creation of the new texture in said new context.
itsmattkc
Simran Brucherseifer