Issue 116339

Summary: OOo freezes for minutes on slide change
Product: Impress Reporter: Andrea Pescetti <pescetti>
Component: viewingAssignee: wolframgarten
Status: CLOSED FIXED QA Contact: issues@graphics <issues>
Severity: Trivial    
Priority: P2 CC: cno, issues, mdxonefour, vitriol_vitriol
Version: OOO330m8Keywords: regression
Target Milestone: 3.4.0   
Hardware: Unknown   
OS: Linux, all   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Attachments:
Description Flags
OOo 3.3.0-RC8 freezes on the second slide none

Description Andrea Pescetti 2011-01-07 00:51:56 UTC
OOo 3.3-RC8 freezes when displaying the presentation I'll attach shortly.

OOo 3.2.1, conversely, handles it without any problems.

To reproduce:
- Open the presentation, F5 to display it full screen.
- The second slide contains an animated image; let it run for a while.
- Click to go to the third slide.

Expected (and working in OOo 3.2.1): the third slide is immediately displayed.

Actual result: OOo freezes for a long time, giving the impression it has become
completely unresponsive; in the end it becomes responsive again, but this takes
unacceptably long (minutes) and leaves many users with the impression that the
process has to be killed.

Credit: first reported at https://bugs.freedesktop.org/show_bug.cgi?id=32861
(the test document is obtained from the one submitted there, removing unneeded
complexity)
Comment 1 Andrea Pescetti 2011-01-07 00:55:02 UTC
Created attachment 75489 [details]
OOo 3.3.0-RC8 freezes on the second slide
Comment 2 wolframgarten 2011-01-07 07:41:55 UTC
Reproducible on OOO330_m18 on Linux. Works under Windows. Reassigned.
Comment 3 strata 2011-01-10 11:55:20 UTC
I have just tested the issue's file with OOo 3.3.0rc9, vanilla, linux, x86-64,
Italian and OOo seems to freeze at all!

I have wait some minutes (too few?), but then I must kill the OOo process.

Carlo
Comment 4 groucho266 2011-02-11 09:36:43 UTC
Reviewed priority.

The freeze is caused by a recent change that was intended to make animations
more smooth.  It prevents some events from being processed while an animation is
running, thereby giving each frame more time to render its content.

The side effect that causes the near-freeze is that the keyboard event for the
ESC key is much more slowly processed than before.
Comment 5 groucho266 2011-03-07 10:00:16 UTC
Fixed by adding a call to Reschedule() from the PostYieldListener (in sd/source/ui/slideshow/slideshowimpl.cxx).  This processes all pending events.  After all, we just want to avoid to yield, not to avoid event processing altogether.
Comment 6 groucho266 2011-03-23 08:14:49 UTC
@wg: Please verify.
Comment 7 wolframgarten 2011-03-30 09:19:55 UTC
Still needs too much time or does not proceed at all..back for a 2nd look.
Comment 8 groucho266 2011-03-31 13:13:04 UTC
There was a problem with the VCL plugin that is used for KDE on Linux: when Application::reschedule(true) is called (the original fix) to process all pending events then the KDE plugin processes only one event.  An all other platforms/architectures all pending events are processed.
Comment 9 groucho266 2011-04-01 07:30:17 UTC
@wg: Please verify.
Comment 10 wolframgarten 2011-04-01 07:55:52 UTC
Aaah! Fixed and verified, works now.