Issue 81959 - Animations slow down extremely after about 20th animation
Summary: Animations slow down extremely after about 20th animation
Alias: None
Product: Impress
Classification: Application
Component: code (show other issues)
Version: OOo 2.3
Hardware: PC Linux, all
: P2 Trivial (vote)
Target Milestone: OOo 2.3.1
Assignee: fredrik.haegg
QA Contact: issues@graphics
Keywords: regression
: 81709 82941 (view as issue list)
Depends on:
Reported: 2007-09-26 11:52 UTC by micha137
Modified: 2008-02-18 14:38 UTC (History)
3 users (show)

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

presentation causing OO-Impress-death, dep on sys-resources might have to run it twice (663.37 KB, application/vnd.oasis.opendocument.presentation)
2007-09-26 12:18 UTC, micha137
no flags Details
simple dummy presentation (12.53 KB, text/plain)
2007-10-08 10:16 UTC, micha137
no flags Details
Presentaion with which the issue very fast gets visible. (6.03 KB, application/vnd.oasis.opendocument.presentation)
2007-10-30 14:55 UTC, fredrik.haegg
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description micha137 2007-09-26 11:52:07 UTC
Well into the presentation, after about 20-30 effects(fly in etc) the effects
(and  other OO-functions e.g. "save") slow down to the point of
(almost?)freezing. Happens on both my Ubuntu systems with 680m5, build 9221.
Does not occur with slightly older developer snapshot 680m2, build 9207

Can provide sample presentation if needed. Seems to occur on all my
presentations which contain a larger number of animations.
Comment 1 micha137 2007-09-26 12:18:06 UTC
Created attachment 48510 [details]
presentation causing OO-Impress-death, dep on sys-resources might have to run it twice
Comment 2 micha137 2007-10-08 10:16:28 UTC
Created attachment 48747 [details]
simple dummy presentation
Comment 3 micha137 2007-10-08 10:23:27 UTC
Hi there,
can please someone have a look at this. I can't believe this issue hasn't even
been looked at since oct 26. 
This is a really serious issue and renders Impress(OO2.3) unusable for real
Just create three pages with listboxes about 12 lines each and let the fly in.
This results in progressive slowdown to the point of freezing.
Comment 4 micha137 2007-10-08 17:13:55 UTC
additional comment:
also happens with build 9207, just takes somewhat longer till memory and
processor capacity are bound to the point of freezing.
System Monitor shows that each time presentation is started, the memory
footprint increases and some additional processor capacity is bound for no
obvious purpose. Closing the file frees some memory, simply opening it again
reallocates the excessive memory even without entering presentation mode.
Processor remains busy even on closing the file.
OO2.2 behaves perfectly regarding memory allocation as well as processing
capacity on the same presentation files.
Comment 5 wolframgarten 2007-10-09 10:23:50 UTC
Sorry, not reproducible on Suse with version 2.3.0.
Comment 6 wolframgarten 2007-10-12 12:12:03 UTC
Tested this again with the final 2.3.0 (build 9221). Still not reproducible.
This may have the same root as 82449..... Can you reproduce this with the
released version?
Comment 7 micha137 2007-10-15 07:27:59 UTC
also occured with the released version and with dev-version build 9225.
Comment 8 micha137 2007-10-24 09:21:27 UTC
with the OO-build declared as "680m5 9221" from the ubuntu repository, the
defect does not occur.
All builds (2.3 stable and dev so far) from the openoffice download page, which
I installed from rpm packages (with the install script via conversion from rpm
to deb by "alien") show the defect.
Comment 9 christian.guenther 2007-10-24 12:47:46 UTC
Set to ne and change the target.
Comment 10 christian.guenther 2007-10-24 12:49:39 UTC
I can reproduce the behaviour with the i_presentationengine autotest on solaris.
Please have a look.
Comment 11 fredrik.haegg 2007-10-30 13:25:10 UTC
*** Issue 82941 has been marked as a duplicate of this issue. ***
Comment 12 fredrik.haegg 2007-10-30 14:55:45 UTC
Created attachment 49270 [details]
Presentaion with which the issue very fast gets visible.
Comment 13 thb 2007-10-30 15:48:25 UTC
@pl: at least part of this problem seems to be caused by the gtk plugin. Running
effects.odp with SAL_USE_VCLPLUGIN=gen works like a charm, reverting to the gtk
plugin, even the first effects of slide 0 in said file are dog slow. Please have
a look.
Comment 14 philipp.lohmann 2007-10-30 17:20:57 UTC
not so
Comment 15 philipp.lohmann 2007-10-30 18:04:41 UTC
some more evaluation on the sparc machine we can witness this on: this happens,
too, with the generic plugin. It seems that there are timer events queing up to
be processed, because the handlers are too slow. However the gtk version of the
event mechanism itself seems to be quite more costly, so that the problem
reproduces more easily on gtk.

This seems to be at least two problems: the gtk timer handling in OOo is showing
too costly  in this case and someone produces more timer events than he can handle.
Comment 16 thb 2007-11-01 21:40:50 UTC
I'm at loss here - cl, any idea what could have caused this regression? IIRC, we
did some changes in the Impress busy loop, though...
Comment 17 thb 2007-11-02 14:29:42 UTC
@cl: thanks for providing the ultimate fix for this
Comment 18 clippka 2007-11-05 12:29:52 UTC
removed the busy loop in slideshowimpl.cxx and replaced it with a system that
uses either PostApplicationEvent or vcl timer. Seems to work pretty well under
solaris. But all platforms must be tested
Comment 19 uwe.luebbers 2007-11-05 14:00:33 UTC
added keyword
Comment 20 clippka 2007-11-05 14:06:22 UTC
*** Issue 81709 has been marked as a duplicate of this issue. ***
Comment 21 clippka 2007-11-06 09:55:14 UTC
verified in cws, back to qa

please note that this issue must be verified on local machines, not via remote
only on all plattforms. It must be checked that different animations runs as
smooth as before, on all plattforms,
Comment 22 fredrik.haegg 2007-11-08 12:50:09 UTC
Verified in CWS "Impress135". The problem doesn't occur anymore.
Comment 23 fredrik.haegg 2008-02-18 14:38:06 UTC