Created attachment 184847 [details] Sample document (ODP extraced from more complex PPTX) This is distilled from a design PPTX I received, shows equally as ODP. There is an extra delay moving from slide 1 (which is essentially empty) to slide 2 (which has an animated GIF) in presentation mode which manifests in one of two ways: - It takes 8s after I hit <next> on slide 1 for slide 2 to appear. - I need to wait 8s before hitting <next> on slide 1 for slide 2 appear without delay. My guess is that something is "preparing" for slide 2, which takes that amount of time, and only when that is complete slide 2 is ready to be transitioned to. Presumably related to the animated GIF? Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 579d144290c1617fdb38d09b30900a6bbe390b8d CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US and all the way back to 7.0, though only starting with 7.2 the animated GIF is rendered with proper transparency instead of background being a black rectangle.
I can also see a noticeable delay when going to the next slide as soon as slide 1 appears. In a master build from today: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: cd20a17ab703e97191b4e3421527267ef82a704f CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded But I see the delay in OOo 3.3 as well: OpenOffice.org 3.3.0 OOO330m20 (Build:9567) The extracted GIF is 13.2 MB. There's related bug 104878 but it's a regression.
I originally encountered this on a HiDPI (3840x2160) system where the delay is 8s. Switching resolution to 1960x1080 it's down to 1-2s.
Attila Szűcs committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/110eb4f6f8ed43faf7d2a4e74bfdcb93934f6439 tdf#153162 Gif load transparency optimization It will be available in 24.8.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.
Created attachment 193476 [details] Improved testcase Let me replace the testcase with a nicer one: same key slide, just easier to operate: 1. Open presentation and enter presentation mode. 2. Hit <space> and time how long the second slide is shown before it automatically transitions to the third. This is how long it takes to prepare the animated GIF.
Gerald, the patch above already made a difference (from 10s to 6s on the test system). Have you tried it? As there are no more obvious bottlenecks in calculations, it would be hard to optimize more. What is the goal?
(In reply to Andras Timar from comment #5) > Gerald, the patch above already made a difference (from 10s to 6s on the > test system). Have you tried it? I am puzzled and cannot explain my own results, alas on my new system it seems the 20240321 daily build (which should not have the patch), the 20240405 daily build (with should have the patch), 24.2.2.2 (from openSUSE Tumbleweed), and 7.6.3.0.0 all take about the same time: 5.3s with a resolution of 3840x2400 and the new testcase (which should not affect timing, just make it easier to reproduce and measure). Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 2d16901bd49fbb3a6c89bd06f6142aaad87be981 CPU threads: 12; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 30c6e51fc9cb0fa864e1755271343d847fcced25 CPU threads: 12; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Do you have an idea what might be going on? (Is the changed code not hit on my system? On Linux? Which system did you run your tests on?)
(In reply to Gerald Pfeifer from comment #6) > (In reply to Andras Timar from comment #5) > > Gerald, the patch above already made a difference (from 10s to 6s on the > > test system). Have you tried it? > > I am puzzled and cannot explain my own results, alas on my new system > it seems the 20240321 daily build (which should not have the patch), > the 20240405 daily build (with should have the patch), > 24.2.2.2 (from openSUSE Tumbleweed), and > 7.6.3.0.0 > all take about the same time: 5.3s with a resolution of 3840x2400 and > the new testcase (which should not affect timing, just make it easier > to reproduce and measure). > > > Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: 2d16901bd49fbb3a6c89bd06f6142aaad87be981 > CPU threads: 12; OS: Linux 6.8; UI render: default; VCL: gtk3 > Locale: en-US (en_US.UTF-8); UI: en-US > > Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: 30c6e51fc9cb0fa864e1755271343d847fcced25 > CPU threads: 12; OS: Linux 6.8; UI render: default; VCL: gtk3 > Locale: en-US (en_US.UTF-8); UI: en-US > > > Do you have an idea what might be going on? (Is the changed code not > hit on my system? On Linux? Which system did you run your tests on?) Andras was missing from CC.