Sluggish/choppy transition when double-clicking another slide-group

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Open a DViz file containing at least 2 slide groups.
2. Send the first slide group to a live output.
3. Double-click on the second slide group to send it live.

I expected a smooth transition on the live output.
Instead, I see a choppy and very slow transition (4 seconds instead of 1).

This is with r440 on Windows XP SP3.  However, it's not a new problem -
it's been occuring since I started looking at this product.

If I single-click on the second slide group and wait for it to fully appear
in the preview pane, and THEN double-click it to send it to the live
output, this problem doesn't occur.  I would guess the problem is that
there are two transitions occuring simultaneously - one in the slide-group
preview pane and another in the live output.  

The live transition should take precedence.  Maybe the slide-group-preview
transition could be disabled or delayed until the live transition is complete?

Original issue reported on code.google.com by kpr...@gmail.com on 5 Dec 2009 at 11:45

[GoogleCodeExporter]

Good suggestion. I'm working on re-designing the "preview" architecture to 
allow for
audio outputs, so I'll add this to work on when I'm inside that part.

Original comment by josiahbryan@gmail.com on 7 Dec 2009 at 5:44

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by josiahbryan@gmail.com on 7 Dec 2009 at 5:44

[GoogleCodeExporter]

I've turned off cross-fading in the preview widget - effective in svn r443. 
check it
out and see if this is resolved for you.

Original comment by josiahbryan@gmail.com on 8 Dec 2009 at 9:58

[GoogleCodeExporter]

Turning off cross-fade for preview definitely helps.  I'm noticing lag time now 
due
to loading images that I wasn't seeing previously (because the image support was
broken...).  But rather than a really slow cross-fade on the live output, the 
lag now
mostly just causes the transition not to start until after the new slide group 
has
loaded.  Maybe some kind of a "pre-load" (possibly in the background?) of all 
the
slide groups in the open project would be needed to improve this experience any 
further? 

Or, just teach users that it's best to click onto the next slide group a couple
seconds before you actually want to go live...

Original comment by kpr...@gmail.com on 9 Dec 2009 at 12:19

[GoogleCodeExporter]

Added pre-load of images used as backgrounds in slides in r449 - however, use at
least 450 for building - windows had issues with r449 that are resolved in r450.

Please let me know if this lag reported in comment 4 is resolved or improved at 
all
with these changes.

Original comment by josiahbryan@gmail.com on 13 Dec 2009 at 3:36

[GoogleCodeExporter]

Tested with r451.  Transitioning between two slide groups seems to be further
improved, though perhaps still not perfect.  May be my hardware is causing the 
lags
though at this point.  I do know my hard drive is not the speediest thing in 
the world.

For what it's worth: if I'm not mistaken, the slight lag that's left is actually
related to building previews for the slides in a non-song slide group.  For 
example,
a slide group that's created for a lengthy scripture passage.  I watched a 
transition
just now that suffered from multiple brief lags, where each lag seemed to 
coincide
with seeing another preview slide (in the "live" pane) being drawn onto the 
screen. 
One possible solution to these lags might be to hold off on drawing the preview
slides if a transition is still active?

Oddly, I was also seeing a UI issue that I thought was contributing to lags.  
If I
double-clicked too fast on a slide group containing more than a trivial amount 
of
text on the first slide, I was seeing the resize-grab-bar (not sure what else 
to call
it) between the preview "column" and the live column shift to the left by maybe 
20
pixels.  Then the buttons and other widgets in the preview column ("Send to 
Output",
"Live" checkbox, "Start" button, etc) moved the left by the same amount.  Then 
all of
the UI elements jumped back to their normal positions and the transition 
proceeded
smoothly to completion.  But after resizing the main app window and the various
slider bars between the panes, I can't cause this "oddity" to recur.  The main 
"DViz"
control window was not maximized, and only a single column of slides were 
visible in
each of the preview and live panes...  Probably not worth tracking down.

Original comment by kpr...@gmail.com on 15 Dec 2009 at 3:31

[GoogleCodeExporter]

Implemented suggested fix. SlideGroupListModel will delay generating icons for 
the
list if a transition is active and resume generating the icons once the 
transition is
complete. Also applied a similar "check for active transition" in 
DocumentlistModel
and DirectoryListModel.

kproth - I know its been over two months since the last comment on this issue - 
but
if you would, when you have time, check and see if the latest revision fixes the
"slight lag that's left." 

Thanks!

Original comment by josiahbryan@gmail.com on 16 Feb 2010 at 3:57

[GoogleCodeExporter]

Placing on Hold till confirmation from original reporter received that the 
issue has
been resolved, at which point the issue will be closed or further work will be 
done.

Original comment by josiahbryan@gmail.com on 16 Feb 2010 at 7:37

• Changed state: Hold

[GoogleCodeExporter]

Assuming fixed (two years since any further problem reports on this issue) - 
closing issue.

Original comment by josiahbryan@gmail.com on 10 May 2012 at 2:37

• Changed state: Fixed