Download it now!
Bug 133355 - High memory usage while in presentation mode with large animated gifs
Summary: High memory usage while in presentation mode with large animated gifs
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
6.1.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectRequest, possibleRegression
Depends on:
Blocks: Memory
  Show dependency treegraph
 
Reported: 2020-05-24 19:16 UTC by Telesto
Modified: 2020-10-19 20:41 UTC (History)
1 user (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

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
Created attachment 166469 [details]
Example file

Lets try different example file. Simple gif of 200 kb.. 2 GB needed to render in presentation mode
Comment 4 Telesto 2020-10-17 20:32:17 UTC
(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
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
(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"?
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..