Description: High memory usage while in presentation mode with large animated gifs Steps to Reproduce: 1. Open the attached file 2. Open an process monitor or another memory tool (which can override presentation mode) 3. Press F5 4. First sheet - nothing interesting (go on) 5. Second sheet -> Animated gif.. nothing wrong (let it animate 5 sec and go on 6. Third sheet -> same gif as 5.. does nothing at first.. memory goes from 400 to 800MB go on 7. Fourth sheet different gif -> let play for a while if you want too.. or go on 8. Again.. a large gif.. let it play for 5 seconds.. and go on Actual Results: Master after ending presentation 1,5 GB 6.3 -> increase between 5-6 rest appears to normal 6.1 -> not working fine 6.0 -> working fine.. Expected Results: Behavior of 6.0... Reproducible: Always User Profile Reset: No Additional Info: Version: 7.0.0.0.alpha1+ (x64) Build ID: b587de60d4e6aa96238766272d94f1499b22f696 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 Attempted multiple bibisects on Windows.. but origin/master 6.0 fine oldest 6.1 broken. Origin/master 6.2 fine. Oldest 6.3 broken.
Created attachment 161241 [details] Example file
For me on Linux, it's about 800MB at the end, but immediately drops to 464MB, so not really something I would classify as a problem. On Windows I had a similar experience, mem use dropping to roughly 200MB Maybe someone improved something during this time, though, so worth a re-test? Version: 7.1.0.0.alpha0+ (x64) Build ID: df74aef7159d7155addf78cfc4d139485945d794 CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: default; VCL: win Locale: fi-FI (fi_FI); UI: en-US Calc: threaded Arch Linux 64-bit Version: 7.1.0.0.alpha0+ Build ID: 9b34dc20b6946698ae6ce2d5d859885bfb444633 CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: kf5 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 16 October 2020
Created attachment 166469 [details] Example file Lets try different example file. Simple gif of 200 kb.. 2 GB needed to render in presentation mode
(In reply to Telesto from comment #3) > Created attachment 166469 [details] > Example file > > Lets try different example file. Simple gif of 200 kb.. 2 GB needed to > render in presentation mode Linux does slightly better job, 'only' 1100 MB Version: 7.1.0.0.alpha0+ Build ID: 943aaf6c61d9594ec229984b5d5801afe5d89024 CPU threads: 2; OS: Linux 5.3; UI render: default; VCL: x11 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
(In reply to Telesto from comment #4) > (In reply to Telesto from comment #3) > > Created attachment 166469 [details] > > Example file > > > > Lets try different example file. Simple gif of 200 kb.. 2 GB needed to > > render in presentation mode > > Linux does slightly better job, 'only' 1100 MB > > Version: 7.1.0.0.alpha0+ > Build ID: 943aaf6c61d9594ec229984b5d5801afe5d89024 > CPU threads: 2; OS: Linux 5.3; UI render: default; VCL: x11 > Locale: en-US (en_US.UTF-8); UI: en-US > Calc: threaded And goes back to 3.3.0; so smells like a different bug, or the actual problem only exposed differently under Win
(In reply to Telesto from comment #3) > Created attachment 166469 [details] > Example file > > Lets try different example file. Simple gif of 200 kb.. 2 GB needed to > render in presentation mode "Needed to render", but what about your original remark of "after ending presentation"?
(In reply to Buovjaga from comment #6) > (In reply to Telesto from comment #3) > > Created attachment 166469 [details] > > Example file > > > > Lets try different example file. Simple gif of 200 kb.. 2 GB needed to > > render in presentation mode > > "Needed to render", but what about your original remark of "after ending > presentation"? Simply not precise. Until reaching the end of they presentation memory will build up to 1,5GB (or the case here 2 GB), it gets released after exiting presentation mode. So the build up is 'only' taking place while presentation mode being active. So 'after' should have been 'at'. And looks like Windows backend doing a duplication of they data. So 1000 MB at Linux ends up 2000 on Windows. Whereas they 1000 MB already rather massive for simple gif. IrfanView needs 1,8 MB. So there is obviously some room for improvement here. But no clue if a bibisect being useful..
(In reply to Telesto from comment #0) > 6.0 -> working fine.. Contradictory. Testing with attachment 166469 [details], oldest and latest commits in Win 6.0 repo use the same amount of memory as 7.1 master: about 1250 MB. Same with oldest of 5.4. I still can't call this a bug and certainly not a regression.
(In reply to Buovjaga from comment #8) > (In reply to Telesto from comment #0) > > 6.0 -> working fine.. > > Contradictory. Testing with attachment 166469 [details], oldest and latest > commits in Win 6.0 repo use the same amount of memory as 7.1 master: about > 1250 MB. Same with oldest of 5.4. > > I still can't call this a bug and certainly not a regression. Lets drop the regression part (taking comment 3 as baseline).. LibreOffice 4.4.7.2 crashes on opening -> passing they 1,2 GB mark (so OOM). So something has improved in non-presentation mode still present in presentation mode And yes, i still call it a bug :-)
Ok, let's change summary accordingly.
Created attachment 166913 [details] Bibisect log This got solved in non-presentation mode with author Armin Le Grand <Armin.Le.Grand@cib.de> 2016-06-03 13:58:40 +0200 committer Caolán McNamara <caolanm@redhat.com> 2016-06-10 14:42:57 +0100 commit 702b58945b51e738cdcc3d383ca38881f9f1338d (patch) tree 9c1958b8c44ee5bbc7803765e498d2208b906556 parent b523e20a8fb8c9c26e7ffdc1b3f5fd06c440985c (diff) tdf#99519 Added more intelligent handling of animated GIFs Isolated to a single Primitive2D class based on the AnimatedSwitch- Primitive2D which does the specializing in one place. Buffers small GIFs completely, handles 1st frame always buffered, huge GIFs get animated by just playing he next frame. To reach more with the current approach we would have to re-implement AnimatedGIF import, replay it internally on a sys-specific Surface and blit the current content (with alpha) to our display https://cgit.freedesktop.org/libreoffice/core/commit/?id=702b58945b51e738cdcc3d383ca38881f9f1338d
@Caolán Armin has introduced a more intelligent handling of animated GIFs. They same trick needs to be implemented for presentation mode; it has exactly the same flaw. I should ask Armin technically, but he is probably not available A warning in advance: the fix is not totally unproblematic; bug 104878. However they current implementation will crash x32 builds and make system going out of mem pretty fast (if enough gifs are used). But feel free to ignore of course :-)
Does this report make sense? There's already bug 104878 and bug 121793, confirmed by Telesto, for which I don't understand why not duplicated, and now again this one.
I wonder if the fixes for bug 153162 have an effect on the slideshow perf.
Same type of memory use behaviour in Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 9b41d33a00763bebd5fc70787052222d35a98a52 CPU threads: 2; OS: Windows 11 (10.0 build 22621); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded