Description: Once a presentation becomes longer and with more existing animation, or elements on slides, its takes longer and longer for the UI to respond to clicks on adding animation effects and to changes to the settings (e.g. Start on Click vs Start with Previous). This can get to extreme situations where a single such action can take well over a minute or two (!) on 4 GHz quad-core machine with 16 GB of RAM. Steps to Reproduce: Create a large(ish) presentation with effects on many slides, and some slides with dozens of elements (albeit grouped). Can't say at this point exactly what it is that contributes to the sluggishness. Actual Results: Adding, modifying or removing an animation effect all become increasingly slow. Expected Results: Adding, modifying or removing an animation effect should be instantaneous. Reproducible: Sometimes User Profile Reset: No Additional Info: Automatic preview is disabled - I'm not running the animation. Also, this happens even if you only have "appear" and "disappear".
Is it possible to add a sample file.. saved they trouble of building one (and we have a reference)
Created attachment 166482 [details] A presentation for reproducing the bug 1. Open the presentation. 2. Duplicate the second-to-last slide. 3. Delete the existing animations. 4. Click the main text box. 5. Select-All (e.g. with Ctrl+A) 6. Press the animation addition green-Plus button LO will be stuck for a very long time - around a minute; at least, that's what I experience.
No repro on Windows Version: 7.1.0.0.alpha0+ (x64) Build ID: 94e6e140491de31c0788c91af855a75a3bb12709 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL Are we talking about GTK3, KDE5 or GEN backend. Suspecting a GTK3 specific issue
(In reply to Telesto from comment #3) > Are we talking about GTK3, KDE5 or GEN backend. Suspecting a GTK3 specific > issue Oh, sorry, I forgot to paste my build info: Version: 7.0.0.3 Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e CPU threads: 4; OS: Linux 5.2; UI render: default; VCL: gtk3 Locale: he-IL (en_IL); UI: en-US Calc: threaded
Hello Eyal Rozenberg, I believe this issue might be fixed now after https://git.libreoffice.org/core/commit/27a4aea50a9efa5c839b0ae2de1f9f14a7782f11. Could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/ ? You can install it alongside the standard version. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the master build
(In reply to Xisco Faulí from comment #5) > I believe this issue might be fixed now after Unfortunately, it's just as bad as before. I should also mention that if you followed the reproduction instructions, you would notice a bit of slowness already in the duplication of the second-to-last slide; and later, after following the instructions, even drag-selecting text within the slide and de-selecting by clicking outside the textbox - is pretty slow (not as slow as animations response).
Bibisected with linux-64-6.3 to https://git.libreoffice.org/core/commit/f331244337a9b2c70ac1bb52b0637c32956b7d91 tdf#123470 textforwarder has stale view of SdrTextObj Adding Cc: to Caolán McNamara
(In reply to Buovjaga from comment #7) > Bibisected with linux-64-6.3 Thanks for that, Ilmari. But - what does that change have to do with modifying page animations? Anyway, see my Redmine issues #3529 and #3570 about encouraging more people to bibisect.
reverting it brings back the problem of https://bugs.documentfoundation.org/show_bug.cgi?id=123470 so some other solution is required
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f8eb28d6b6e306d87e5cec3f1b6f83c841a5f01e tdf#137571 use XActionGuard to lock blocks that don't need updating It will be available in 7.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
done in trunk, backport to 7-3 in gerrit
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-3": https://git.libreoffice.org/core/commit/c1fd702dacec60cbd87531e9f11caf3d0cfbb155 tdf#137571 use XActionGuard to lock blocks that don't need updating It will be available in 7.3.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.