Step 2: Save as copy

Confirmed, but I think devs will shoot this down as an outrageous nitpick :)

Arch Linux 64-bit
Version: 6.2.0.0.alpha0+
Build ID: 860a9daf2b45942a4b10ff22d36aa3fe29be19f4
CPU threads: 8; OS: Linux 4.17; UI render: default; VCL: gtk3; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group threaded
Built on July 14th 2018

With the example file, initial res mem use was about 660M. It jumped to about 1100M when saving as copy.

I created a new file with 4 new pages and 4 new unique images (using the png as base). Initial res mem was now 1850M, it jumped to 2994M after saving as copy.

Eike had some concerns regarding documents with many images and possibly no cap for the mem use, so let's set to new.

Adding bibisectRequest; seems practical..

@Buovjaga 
Slightly off topic, but I still get confused by the term 'regression'. The QA has a user perspective and DEV's have a technical approach. Which isn't to helpful, in my opinion. Not sure if there is need for some clarification (or more confusing keywords)

My own list of sub-types:
a. A regression between versions of LibreOffice (the behavior changed to the worse, sec). Uninterested in how and why
b. Regression which happen outside the LibO code, due a change in the operation system (the code has not changed, isn't working anymore as expected) 
c. Technical approach: unexpected /unintended side-effect of a code change. Which includes a, maybe b but not c
sub a. something that the DEV broke with his commit (in strict sense)
sub b. something that the DEV broke, because of brokenness down te road because of a different code path
sub c. something that the DEV already expected to happen; (for example: harmonising font rendering made latin font handling a lot slower)

(In reply to Telesto from comment #4)
> @Buovjaga 
> Slightly off topic, but I still get confused by the term 'regression'. The
> QA has a user perspective and DEV's have a technical approach. Which isn't
> to helpful, in my opinion. Not sure if there is need for some clarification
> (or more confusing keywords)
> 
> My own list of sub-types:
> a. A regression between versions of LibreOffice (the behavior changed to the
> worse, sec). Uninterested in how and why
> b. Regression which happen outside the LibO code, due a change in the
> operation system (the code has not changed, isn't working anymore as
> expected) 
> c. Technical approach: unexpected /unintended side-effect of a code change.
> Which includes a, maybe b but not c
> sub a. something that the DEV broke with his commit (in strict sense)
> sub b. something that the DEV broke, because of brokenness down te road
> because of a different code path
> sub c. something that the DEV already expected to happen; (for example:
> harmonising font rendering made latin font handling a lot slower)

I'm not seeing the split in perspective. The user perspective might initially be hazy because of lack of understanding, but surely we arrive to a common perspective after discussion and investigation?

If a so-called regression is a change in behaviour that was pushed by the design team, then the users just need to accept it.

If there is an argument over changing use of systems resources (such as more mem use and less CPU), I think users without insights into specifics should stay out of the discussion. There is no use arguing, if one does not understand the reasoning behind a change and is not able to propose an alternate solution. This does not mean that testers should skip altogether investigating alarming things they observe.

Your example "harmonising font rendering made latin font handling a lot slower" is still a regression, but it requires a completely new approach as a component was changed wholesale. It is thus a lot less trivial than the usual regressions caused by a mistake or some unforeseen side-effect.

I don't see how your case b. has a relation to LibreOffice devs, or maybe you meant "the DEV of operating system X broke something". We have to work around OS bugs or change features accordingly, yes, but these cases cannot be called our regressions, because there is nothing to bisect.

I tried bibisecting this with win 6.1 several times, last time with rm -rf instdir/cache instdir/user on every step. I ended up with bogus results every time.

Why do you think that is a bug? RAM is made to be used.

No need to do a copy to bump the RAM consumption, it is enough to select one of the pictures. The RAM consumption is bigger if PNG is selected than JPEG.
With LO 6.1.1.0.0+ under Ubuntu 16.04 x86-64: 548 MiB when the file is loaded, 787 MiB when the JPEG is selected, 987 MiB when the PNG is selected. RAM 

If you want smooth scroll and fast display of pictures you need to use the RAM. I do not see any bad behavior here.

Best regards. JBF

Bug 119023 is probably more representative (probably the same root cause)

I tested this bug with 
Version: 6.2.0.0.alpha0+
Build ID: 144da6d5079bcd435e6637cb5cf95305f3ec1306
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-10-12_02:13:01
Locale: ro-RO (ro_RO.UTF-8); Calc: threaded

And it is much better than with previous versions...

Please test again...

Yep, I think this can be closed. Memory bump is not huge and release is not delayed.

Arch Linux 64-bit
Version: 7.1.0.0.alpha0+
Build ID: de1b634a151c198584dc152676183f519c50a2da
CPU threads: 8; OS: Linux 5.6; UI render: default; VCL: kf5
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Built on 12 June 2020

(In reply to Buovjaga from comment #10)
> Yep, I think this can be closed. Memory bump is not huge and release is not
> delayed.
> 
> Arch Linux 64-bit
> Version: 7.1.0.0.alpha0+
> Build ID: de1b634a151c198584dc152676183f519c50a2da
> CPU threads: 8; OS: Linux 5.6; UI render: default; VCL: kf5
> Locale: fi-FI (fi_FI.UTF-8); UI: en-US
> Calc: threaded
> Built on 12 June 2020

Somewhat related.. Opening the file & clicking the image = OOM Crash -> With x86
Version: 7.1.0.0.alpha0+ (x86)
Build ID: 26483950760f0aac7bc45e93db4127f66a98fdc6
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