Issue 116339 - OOo freezes for minutes on slide change
Summary: OOo freezes for minutes on slide change
Alias: None
Product: Impress
Classification: Application
Component: viewing (show other issues)
Version: OOO330m8
Hardware: Unknown Linux, all
: P2 Trivial (vote)
Target Milestone: 3.4.0
Assignee: wolframgarten
QA Contact: issues@graphics
Keywords: regression
Depends on:
Reported: 2011-01-07 00:51 UTC by Andrea Pescetti
Modified: 2017-05-20 10:30 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

OOo 3.3.0-RC8 freezes on the second slide (242.20 KB, application/vnd.oasis.opendocument.presentation)
2011-01-07 00:55 UTC, Andrea Pescetti
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
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
(the test document is obtained from the one submitted there, removing unneeded
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.

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.