Closed GoogleCodeExporter closed 8 years ago
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
Original comment by josiahbryan@gmail.com
on 7 Dec 2009 at 5:44
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
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
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
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
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
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
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
Original issue reported on code.google.com by
kpr...@gmail.com
on 5 Dec 2009 at 11:45