Description: The example uploaded is a single slide with five animation. The first two are acceptable, but from the third one the slideshow becomes painfully slow. Steps to Reproduce: 1.Start the slideshow 2.Click the mouse or press an arrow key 3.Go to No. 2 and loop Actual Results: From the third animation you can almost go and get a coffee before the result shows up Expected Results: Animation should continue at normal speed Reproducible: Always User Profile Reset: No Additional Info: Version: 7.0.0.3 (x64) Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: en-GB (en_GB); UI: en-GB Calc: threaded
Created attachment 164215 [details] Example file: one slide, five animation, from the third one it gets painfully slow
Slow with 7.1 and with 6.0 and with Versie: 4.4.7.2 Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600 Locale: nl_NL
Hello Massimo, 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
Dear Massimo, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Still painfully slow. Here is the version of LO I am currently using Version: 7.1.5.2 (x64) / LibreOffice Community Build ID: 85f04e9f809797b8199d13c421bd8a2b025d52b5 CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: default; VCL: win Locale: en-GB (en_GB); UI: en-GB Calc: threaded
Confirming laggy performance with Version: 7.2.0.3 / LibreOffice Community Build ID: 2a7ea282da28d665a7dc086360567b4aea27bf08 CPU threads: 8; OS: Mac OS X 11.5.2; UI render: default; VCL: osx Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded Setting to new, since this has also been confirmed by Telesto.
Still confirmed on Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7713d916e06a8388f849a758f928cbcfded6c0ae CPU threads: 8; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: fi-FI (fi_FI); UI: en-US Calc: CL threaded
Created attachment 197586 [details] Perf flamegraph of third animation Took a perf trace of the animation that is [011] flying in from the left. It's not coffee-fetchingly slow, though. A few seconds. In the flamegraph we see lots of time spent in basegfx::utils::isPointOnPolygon and basegfx::utils::isPointOnLine Arch Linux 64-bit Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ccb96251ea15c3252010416377dd185205206cbd CPU threads: 8; OS: Linux 6.11; UI render: default; VCL: kf6 (cairo+wayland) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded Built on 12 November 2024