While the auto-cache will always default to on, there are cases where the
user may not want the viewer to barrel ahead caching something (footage
viewer for instance or if the user is making a lot of changes in a short
amount of time).
Implemented a smarter auto-cache that's context sensitive. Caching will
automatically pause when playback begins or values are being changed and resume
when inactive.
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.
In the previous commit, we added a dialog to give users options when dropping
footage on a sequence-less timeline panel. However some users will have a
preferred behavior that they'd want every time without having to go through
the messagebox, so we add a "don't ask again" option that stores the setting
in the application config.
Previews don't need to be rendered full resolution, particularly since the
preview is hardly ever 1:1 size of the sequence. The functionality to render
at lower resolutions already existed, but there was no UI for it. This commit
implements UI to set the resolution divider on the viewer.
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.
Implementation isn't perfect yet, viewer/renderer doesn't update yet when
the preference is changed so a sequence needs to be re-opened for the change to
take effect.
Previously we had no disk management whatsoever, so we cleared the cache on
every close just to prevent clogging up tester disk space. Now that we are
implementing disk management, there are better things to do on close regarding
disk cache. However, some users may still wish for the app to delete the cache
on close, so it's provided as an option.
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.
itsmattkc