Bug 133355 - Optimise memory use for large animated gifs
Summary: Optimise memory use for large animated gifs
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
5.2.0.4 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: perf
Depends on:
Blocks: Memory
  Show dependency treegraph
 
Reported: 2020-05-24 19:16 UTC by Telesto
Modified: 2024-05-03 12:45 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file (7.72 MB, application/vnd.oasis.opendocument.presentation)
2020-05-24 19:17 UTC, Telesto
Details
Example file (219.63 KB, application/vnd.oasis.opendocument.presentation)
2020-10-17 19:20 UTC, Telesto
Details
Bibisect log (2.92 KB, text/plain)
2020-11-01 19:38 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-05-24 19:16:37 UTC
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.
Comment 1 Telesto 2020-05-24 19:17:01 UTC
Created attachment 161241 [details]
Example file
Comment 2 Buovjaga 2020-10-16 13:23:27 UTC
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
Comment 3 Telesto 2020-10-17 19:20:54 UTC Comment hidden (obsolete)
Comment 4 Telesto 2020-10-17 20:32:17 UTC Comment hidden (obsolete)
Comment 5 Telesto 2020-10-17 20:50:06 UTC
(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
Comment 6 Buovjaga 2020-10-18 14:22:23 UTC Comment hidden (obsolete)
Comment 7 Telesto 2020-10-19 20:41:52 UTC
(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..
Comment 8 Buovjaga 2020-10-30 14:48:05 UTC Comment hidden (obsolete)
Comment 9 Telesto 2020-10-30 15:21:36 UTC
(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 :-)
Comment 10 Buovjaga 2020-10-30 17:37:18 UTC
Ok, let's change summary accordingly.
Comment 11 Telesto 2020-11-01 19:38:58 UTC
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
Comment 12 Telesto 2020-11-01 19:48:31 UTC
@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 :-)
Comment 13 Timur 2020-11-29 09:02:55 UTC
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.
Comment 14 Buovjaga 2024-05-03 12:11:23 UTC
I wonder if the fixes for bug 153162 have an effect on the slideshow perf.
Comment 15 Buovjaga 2024-05-03 12:45:51 UTC
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