Description: Memory usage around 1000 MB for 70 page document with file size of 27 MB (images) Steps to Reproduce: 1. open attachment 164149 [details] 2. Take process manager 3. Scroll down.. like you normally do (you might use multi-pageview) -> 900 MB 4. Hit export PDF button.. and save notice bump to 1200 Actual Results: Around 1000 MB Expected Results: 400 MB? Reproducible: Always User Profile Reset: No Additional Info: Found in Version: 7.2.0.0.alpha1+ (x64) / LibreOffice Community Build ID: 3b57ebb445df8a2bc3d916ea79f8af45e20e4e62 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 not in Version: 6.4.0.0.beta1+ (x64) Build ID: 20be5cd0bdc57d812bf34a2debfe48caa51de881 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL
Also in Version: 7.0.0.0.beta1+ (x64) Build ID: 2891e91a513520d68ea2b8c59c14335861a15253 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
My guess, catching the same stuff twice. 1. at Cairo commit 828504974d70111e4a35b31d579cf42fe660a660 [log] author Armin Le Grand (Collabora) <armin.le.grand@me.com> Fri Feb 21 16:58:17 2020 +0100 committer Armin Le Grand <Armin.Le.Grand@me.com> Fri Feb 21 20:16:59 2020 +0100 tree 4c2f7720b3efaecf55b8fa7b9b3eeccb278160e6 parent 813cde918338bccc4f711230616340cad2c1d4a0 [diff] tdf#130768 speedup huge pixel graphics Cairo 2. At in depended cache at Skia Both landing in 7.0
*** Bug 141814 has been marked as a duplicate of this bug. ***
Skia related. I got ~900mb of used memory after scrolling down of all document in Version: 7.2.0.0.alpha1+ (x64) / LibreOffice Community Build ID: 31ed81ea71a20ec119805f66a42f99b3f80d2dc5 CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: ru-RU Calc: CL but, when I checked it with disabled Skia I got only ~500mb of used memory . and I'm not sure it's a bug. Only Lubos can say it for sure. I set this one to NEW (because I really see the difference in used memory). Let's wait
on Windows 7: 7.0 - ~500mb with Skia enabled (oops!) 7.1 - ~700mb with Skia enabled so strange
(In reply to Roman Kuznetsov from comment #5) > on Windows 7: > > 7.0 - ~500mb with Skia enabled (oops!) > 7.1 - ~700mb with Skia enabled And how much is it with Skia disabled? I don't see any difference. > so strange The document contains ~0.5G of image data, so it's not really so strange. This is a trade-off between between memory and speed.
(In reply to Luboš Luňák from comment #6) > (In reply to Roman Kuznetsov from comment #5) > > on Windows 7: > > > > 7.0 - ~500mb with Skia enabled (oops!) > > 7.1 - ~700mb with Skia enabled > > And how much is it with Skia disabled? I don't see any difference. You should open the file and scroll it to its end using any method (mouse wheel or Page Down key) 515 mb without Skia enabled 675 mb with Skia enabled in Version: 7.3.0.0.alpha1+ (x64) / LibreOffice Community Build ID: 4be0ae19065b1b50870bc0b2a28189ad39c96a8a CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL
Dear Telesto, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Unchanged Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ff3fb42b48c70ba5788507a6177bf0a9f3b50fdb 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 threaded
(In reply to Telesto from comment #2) > My guess, catching the same stuff twice. > > 1. at Cairo > commit 828504974d70111e4a35b31d579cf42fe660a660 [log] > author Armin Le Grand (Collabora) <armin.le.grand@me.com> Fri Feb 21 > 16:58:17 2020 +0100 > committer Armin Le Grand <Armin.Le.Grand@me.com> Fri Feb 21 20:16:59 2020 > +0100 > tree 4c2f7720b3efaecf55b8fa7b9b3eeccb278160e6 > parent 813cde918338bccc4f711230616340cad2c1d4a0 [diff] > tdf#130768 speedup huge pixel graphics Cairo > 2. At in depended cache at Skia > > Both landing in 7.0 I confirm that in win64-7.0 commit 828504974d70111e4a35b31d579cf42fe660a660 with Skia clearly shows the big memory use. The preceding commit goes down to 100MB even with Skia active.