Remove the sum, add some commments, and
make it scale to the full window.
TODO:
* Hook up CM.
* Add UI for intensity
* Add lines at 20% increments, plus under /
overshoot?
* Add UI for increments.
Before we checked data types to ensure compatibility, but some nodes (e.g. the
math node) may be compatible despite a not apparently compatible data type.
We allow users to make any connection quickly this way.
The first in many NodeView improvements. Up until now, nodes have been forcibly
auto-arranged, which has worked as a reasonable stop-gap just so that all the
nodes are visible during testing/development. However this does not make a good
user experience.
We move the auto-arrange code to a manual function that can be used when the
user or program deems it necessary, and also abstract the node positions so that
the view can ultimately determine the exact amount of spacing (useful for
changing DPIs) or orientation, so users can direct the flow whichever way they
want.
Rather than plugging a matrix into the video input node, the matrix is now
multiplied by the video input using a math node. This is probably more
sensible from a user perspective.
This also means the renderer is tolerant of texture sizes that are not equal
to the sequence size, however most nodes will downsample the texture to the
sequence size (and if not, it will be downsampled once it is cached). Textures
will still *always* be in reference space and the sequence's format. This seems
like the best compromise between backend and frontend congruity.
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.
Results are identical (tested with Olive 0.1.x). Using a straight multiply is faster if the compiler doesn't optimize pow(). It's also safer because with pow(), [the result is undefined if x<0 or if x=0 and y≤0](https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/pow.xhtml).
Troy James Sobotka