Description: Lots of memory used for inserting an image (fine at save & reload) Steps to Reproduce: 1. Open Draw 2. Tools -> Options -> Advanced -> Expert settings -> Search Undo and set it to 0 3. Quite & Relaunch 4. Open the attached file (blank file 3 pages) 5. Download and save https://photojournal.jpl.nasa.gov/jpeg/PIA16919.jpg https://mars.nasa.gov/system/resources/deepzooms/24797_PIA23623_revised.jpg 6. Open an memory monitoring tool 7. Insert 24797_PIA23623_revised.jpg twice & PIA16919.jpg once (everything on separate sheet/page 8. Memory usage will be around 1,9 GB 9. Save.. memory usage around 2,5 GB -> Drops back after save to 1,8 GB 10. Close -> Memory usage drops to 150 mb 11. Reopen the file 12. Click on all 3 page.. even shake the image a bit.. memory usage will be around 1.2 - 1,3 GB Actual Results: 1,9 Expected Results: 1,3 GB Even nicer would be the memory usage of 6.4 after save & reload: 602 MB Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.0.0.alpha0+ (x64) Build ID: 006c65bbd472cb1d7d44e095714e28190b76be0d CPU-threads: 4; Besturingssysteem: Windows 6.3 Build 9600; UI-render: Skia/Rooster; VCL: win Locale: de-DE (nl_NL); GI: nl-NL Calc: CL
Note to myself Bump on file save already present with LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
Created attachment 162474 [details] Example file
Another observation.. LibreOffice 7.0 Windows (GDI) needs structurally +/-90 MB more RAM over the full line of actions compared to Linux (gen) 7.0. Not sure why.. not able to bibisect either.. since x64 bibisect builds are starting from 6.4 So I would prefer LibrOffice Linux 7.0 as benchmark, and not LibO 7.0 Windows GDI ;-). Not that the last 45 MB matters to much...
Bitmap data cannot be shared between LO (using 24bpp) and Skia (using 32bpp). Maybe one day when LO code becomes flexible about what the best format for a bitmap is.
(In reply to Luboš Luňák from comment #4) > Bitmap data cannot be shared between LO (using 24bpp) and Skia (using > 32bpp). Maybe one day when LO code becomes flexible about what the best > format for a bitmap is. As this bug description more a combined'of multiple observations, lets split it up a bit (for my understanding) 1) The difference on file open between Skia 1,3 vs 870 GDI MB is based on the difference between 23bpp and 32bbp? 2) Memory usage after inserting the 3 files = 1,9 GB Memory usage when reopening the saved file + moving images = 1,3 GB is something else. unrelated to Skia 3) Memory usage from 1,8 GB to 2,5 GB on save is expected.. As I still not sure what the export filter actually does.. Is the image read again into memory for some file information or something like that. Its not image compression/ nor the plain image itself (75 + 75 + 7,5 MB). It seems unnecessary at plain sight
*** Bug 134327 has been marked as a duplicate of this bug. ***
Luboš Luňák committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a9f68d9d9ae8d7c8f79152055795044993b252ea don't duplicate large memory usage in SkiaSalBitmap (tdf#134342) It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.