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.
Gerald, when you say HiDPI, does that include display scaling? I can reproduce slower results with 4K and 200% scaling, but it also varies by build. Interestingly, my symbol-enabled local build is consistently slower than the TDF release or bibisect builds. I'm attaching flamegraphs, hopefully it's still useful, at least for finding the source of difference. The main difference seems to be that CairoCommon::copyWithOperator takes up much more time in HiDPI mode than in FullHD mode. On my Ubuntu 22.04 system, I see the following results: Hi-DPI: - own build: 5.1 s - daily build: 5.1 s - 24.2.0.3: 3 s - bibisect build: 2.6 s 4K: - own build: 3.7 s - daily build: 3.5 s - 24.2.0.3: 2.3 s - bibisect build: 2 s FullHD: - own build: 3.6 s - daily build: 3.7 s - 24.2.0.3: 2.3 s - bibisect build: 2 s Conclusion: - daily build and own build behave the same, but different from official TDF build and bibisect build, - 5.1 s is close to the time reported by Gerald in comment 6. - there has been a ~0.3 s improvement since 24.2. - pinpointing small performance differences is hard due to reaction time.
Created attachment 193791 [details] Flamegraph (HiDPI)
Created attachment 193792 [details] Flamegraph (FullHD)
Performance also changed several times in the past, here are the major changes between 6.0 and 7.2 (performance slightly improved further in two small steps since then). Some of these commits also introduced bugs, like the 2nd step, or bug 160680 (the latter didn't come with a perofrmance change). These timings were measured with the bibisect builds. 1. In 6.0, from 2.7 s to 8 s https://cgit.freedesktop.org/libreoffice/core/commit/?id=d148340babf6c973f7d463909d7a51e16c953248 author Caolán McNamara <caolanm@redhat.com> 2017-07-26 14:37:40 +0100 committer Caolán McNamara <caolanm@redhat.com> 2017-07-26 17:58:47 +0200 "Resolves: tdf#104141 CAIRO_FORMAT_A1 vs N1BitLsbPal" 2. In 6.1, from 8.1 s to 5 s (it also added a buggy black background) https://cgit.freedesktop.org/libreoffice/core/commit/?id=ae11dec72099fafc807d13b7169bd3177e9d539f author Vasily Melenchuk <Vasily.Melenchuk@cib.de> 2018-03-06 16:23:40 +0300 committer Noel Grandin <noel.grandin@collabora.co.uk> 2018-03-14 11:13:52 +0100 "tdf#115297: 1bit images displaying fixed (again)" 3. In 7.2, from 5 s to 3.3 s https://cgit.freedesktop.org/libreoffice/core/commit/?id=b153d147c9d813f78dd551fc186c261f52c929a1 author Noel Grandin <noel.grandin@collabora.co.uk> 2021-04-28 15:27:14 +0200 committer Noel Grandin <noel.grandin@collabora.co.uk> 2021-04-29 08:40:56 +0200 "remove support for BITMASK in vcl backends" ======== The below observations were tested using FullHD resolution, but I assume the behavior is similar with HiDPI. Until 6.1, there was a caching mechanism, and while the first slideshow takes a bit longer, subsequent slideshows switch to the slide with the animated GIF very quickly. However, starting from the following commit in 6.1, the GIF is already shown quickly during the first slideshow: https://cgit.freedesktop.org/libreoffice/core/commit/?id=7b355669c6ddeab2e6cec692d6afdff41c61d0fb author Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk> 2018-02-13 21:49:57 +0900 committer Tomaž Vajngerl <quikee@gmail.com> 2018-02-14 07:47:26 +0100 "shapes: don't use "GraphicURL" property, always use "Graphic" " This changes with the following commit, after which all kinds of caching seems to be gone, times are uniformly slower regardless of how many times the slideshow is shown: https://cgit.freedesktop.org/libreoffice/core/commit/?id=7b355669c6ddeab2e6cec692d6afdff41c61d0fb author Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk> 2018-04-14 15:13:05 +0900 committer Tomaž Vajngerl <quikee@gmail.com> 2018-04-20 09:15:22 +0200 "Function to load graphic swapped out (loaded on demand)"
Created attachment 193846 [details] Flamegraph_before_patches
Created attachment 193847 [details] Flamegraph_after_patches
Created attachment 193848 [details] Flamegraph_image_before_patches
Created attachment 193849 [details] Flamegraph_image_after_patches
made a gerrit PR: https://gerrit.libreoffice.org/c/core/+/166608 it is not merged but i share my test results. Now I tested it on openSUSE Leap 15.4 (installed on a virtualbox) Used improved testcase, on 3840x2160 fullscreen.. had an opned Presenter window with almost the same size. (but the slides in the Presenter are smaller) I attached a before and an after flamegraph. (svg, and png format) Without my 2 patches it was ~18.5 sec to start playing the animation after i pressed space. With my 2 patches it was ~7.9 sec Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 9ad0eb9a62b572b15ae0bfd31674aedd77eb4761 CPU threads: 8; OS: Linux 5.14; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Unfortunatelly there is a lot of things that can make Gif loading slower or faster.. even GPU matter... or LO settings (at first i tested in a windows system.. there getAnimationFromGraphic was much faster.. so mostly ReadGIF was slow there) in my openSuse case (and Aron case as well) getAnimationFromGraphic was the slowest thing so i focused on it: made it not prepare the whole animation at once.. it does only 10/134 frames in this test case.. and prepare all others later.. (but load smaller animations at once) so that is 13 times faser now. It now loads the other frames while it is played. the 2. slowest things are the 2x ReadGIF. (aron had only 1.. probably he did not had presenter opened) but 40% of the ReadGIF is the AlphaMask::Invert() that i eliminated.. so they are 1.66 times fatser as they was before. maybe we could try to save ReadGIF data that was loaded at presenter... and reuse it when it is loaded at slideshow... but that would be an ugly hack... because they are totally different place.. and used differently... and does not matter if presenter is not opened... There is not really other slow thing for us... In my OpenSuse case there was a bitmap::scale (for the presenter) that is somewhat slow.. but that is only 11.8% of the 'after patches' result.. Aron did not had that but probably he did not opened Presenter. My windows system also not had it... So if your system will be still uneffected by my patches.. then we should try to check a flamegraph on your system.. to see what eats the time there.
I think worth checking ReadGIF which is called from ImpGraphic::SwapIn in two different places to find out if it is either a) the same Graphic in both cases and there was a SwapOut for some reason, and what that reason was, timer, size or whatever b) actually a different Graphic and we load it twice.
Attila Szűcs committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/89998a744f9ee8efa40c0e1cb7bdbc783d3414fa tdf#153162 Animation load 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.
(In reply to Caolán McNamara from comment #17) > I think worth checking ReadGIF which is called from ImpGraphic::SwapIn in > two different places to find out if it is either > a) the same Graphic in both cases and there was a SwapOut for some reason, > and what that reason was, timer, size or whatever > b) actually a different Graphic and we load it twice. Unfortunatelly they are different instances of Graphic. :( And both created only temporarily locally.. and got deleted affter its data is used.
(In reply to Aron Budea from comment #8) > Gerald, when you say HiDPI, does that include display scaling? I can > reproduce slower results with 4K and 200% scaling Yes, this is what I've been mostly using: 4K and 200% scaling.
Gerald, Can you check with the last merged patch: https://git.libreoffice.org/core/commit/89998a744f9ee8efa40c0e1cb7bdbc783d3414fa tdf#153162 Animation load optimization I also attached some test results in an openSuse.
I think I have excellent news: 24.2 24.8 +----------------- 1920 x 1200 | 3.3s -> 1.0s 100% scaling | | 3840 x 2400 | 6.2s -> 1.3s 200% scaling | For Version: 24.2.4.0.0+ (X86_64) / LibreOffice Community Build ID: 2dd760424554d597eb93fb6bc96ffddc9c5f1b18 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: 2f5ab5b8e7bd7dd06e00153abb77a69e5d192dd2 CPU threads: 12; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US