Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||OOo freezes for minutes on slide change|
|Product:||Impress||Reporter:||Andrea Pescetti <pescetti>|
|Status:||CLOSED FIXED||QA Contact:||issues@graphics <issues>|
|Priority:||P2||CC:||cno, issues, mdxonefour, vitriol_vitriol|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
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.