There were a lot of issues that arose from trying to make GUI changes
from another thread (even though we ran those functions in the right
thread). Now we store layout information until the end of the load and
make the changes then. This works much better from both a business logic
and user experience perspective.
Also prevents multiple sequences from taking focus during load and
starting a render job.
Viewer init was kind of too late since in many cases the sequence
would start caching and crash the app before the user could even read
the message. Moving to the startup makes it clearer from the beginning.
Original fix was wrong, this sorts it out I think. Delta values had to
be doubled as we're in Clip space (I think) and the matrix
multiplication order had to be swapped around.
Updated one of the signla/slot pairs to be simpler as we no longer need
to pass the zoom percentage back and forth.
If Hand Tool is selected we can now drag with a left click AS WELL AS
middle click. This keeps the view behaviour in line with other widgets
in Olive.
For simplicity it does not use handmovableview.
The translation needs to be scaled relative to the zoom percentage so
we get sensible movement when dragging. Dragging is also disabled when
the image is smaller than the container widget.
Re-orders the initialisation of some variables to stop a compile
warning on Travis.
Had to separate zoom and translate matrices to stop the zoom being
applied to itelf. This also required adding separate get/set functions
for each matrix and a GetcombinedMatrix() funtion.
Added those functions ot other files where needed ut may be wrong. Need
to look at export.cpp
Also changed the mouse move and press events to make translation work.
ProgressDialog doesn't have to worry about the platform anymore, now
MainWindow will determine what to do or whether to ignore certain progress
indicator functions.
Previously, audio was all queued first and would therefore all have to
finish before any video frames could start caching. No longer! Now they're
queued side by side so users won't have to wait for audio to finish before
their cached frames come in.
These are two changes that speed up when frames start getting rendered
and processed (particularly for larger scale projects):
* Sorting of time beforehand was done to optimize decoding but is actually
unnecessary since the frames are already sequential when they're retrieved
from the range. As long as we maintain that order, no sorting is required.
This speeds up caching IMMENSELY.
* Evaluate hashes concurrently while retrieving frames. Before, this was
done before any rendering and could therefore delay rendering by several
seconds. Doing them concurrently means frames start rendering almost
immediately and further hashes can be analyzed while we wait for frames to
finish rendering.
itsmattkc
Thomas Wilshaw