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 ;) )
When nodes with keyframes were copied their parent NodeInput was not
set properly leading to a segfult when key->GetParent was called in
KeyframeViewItem::UpdatePos().
This fix properly sets parent_ when keys are copied.
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.
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.
Implemented the ability to copy/paste blocks/clips in the timeline. This did
require some large scale changes and reworking of the copy/paste system
introduced a few commits ago, but should be largely functional now.
Should address any XML parsing issues and allows for simpler, more maintainable
code. Should also address a crash that could occur when pasting nodes that had
inputs that weren't copied.
for UI representations
Allows properties to be set without adding explicit extra members to NodeInputs.
Crucially this means parameters like slider value representations (percent,
decibel, etc.) can be set from NodeInputs now.
When adjusting a slider, keyframe time, or curve value, it is undesirable to
re-cache the entire affected area while the user is still dragging UI objects.
Since the video is unlikely to be playing, the priority must go to the
currently active frame so the user gets visual feedback on the rendered image
as soon as possible. This was implemented in some areas, but this commit should
have that functionality in all areas.
Footage is a special case where the node parameters can reference objects that
exist outside of the graph. Therefore specific code is needed to
serialize/deserialize.
The import function was written early on in the rewrite as a multithreaded
background task that was considered somewhat flawed. While it worked for the
most part, there were possibilities of race conditions that could have
potentially been fatal, particularly since media could theoretically be
deleted while the import/probe tasks were running in the background.
With the save/load functions coming in, it became even more complicated as
projects may include metadata about the footage that can't be implemented
easily when the footage is imported/probed in the background. Making importing
a modal task fixes all of these issues, it's still done in a background thread
to not hang the GUI thread, but the GUI thread can be briefly "paused" in a
user friendly way so that all these functions can be safer.
Since rationals aren't a known Qt format, the QVariant container can't
automatically convert them to and from strings (for XML serialization). We have
to hijack these functions and do the conversion manually for those types.
Also moved the block name type to a node input, which means it's serialized
and copied by default (I'm not sure why it wasn't already like this).
Since we load in a separate thread, when the QObject based objects are
instantiated, they're created with affinity to that separate thread. Now we
specifically ensure they are moved to the main thread after their creation.
This adds the ability to keyframe more than one value per input (e.g. a vec2,
vec3, etc.) so that you can animate, for example, an X axis separately from a
Y axis.
To allow keyframing of each axis of a vector 2/3/4, without simply separating
the inputs for each axis, the NodeInputs need to support more than one keyframe
track with the ability to merge them into a single value when necessary.
itsmattkc