Apache OpenOffice (AOO) Bugzilla – Issue 81959
Animations slow down extremely after about 20th animation
Last modified: 2008-02-18 14:38:06 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.
Created attachment 48510 [details] presentation causing OO-Impress-death, dep on sys-resources might have to run it twice
Created attachment 48747 [details] simple dummy presentation
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 presentations. 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.
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.
Sorry, not reproducible on Suse with version 2.3.0.
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? Thanks.
also occured with the released version and with dev-version build 9225.
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.
Set to ne and change the target.
I can reproduce the behaviour with the i_presentationengine autotest on solaris. Please have a look.
*** Issue 82941 has been marked as a duplicate of this issue. ***
Created attachment 49270 [details] Presentaion with which the issue very fast gets visible.
@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.
not so
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.
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...
@cl: thanks for providing the ultimate fix for this
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
added keyword
*** Issue 81709 has been marked as a duplicate of this issue. ***
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,
Verified in CWS "Impress135". The problem doesn't occur anymore.
.