Description: When working with hi-res images the system is extremely slow. It is as if the system works on the full uncompress image in full resolution instead of a scaled down version of the same. Steps to Reproduce: 1. New text document 2. Insert attached image 3. Write text Actual Results: The program is now very slow. Expected Results: Same speed as if the image had been in low-res. Looking at the memory and CPU usage it looks as if Writer is working on the full-resolution image all the time. It would be much preferable if Writer cached a version scaled for the current need and worked on that; and only recomputed a new scaled version when the image is resized or zoom is changed. Microsoft Word has no problem using the hi-res image. Reproducible: Always User Profile Reset: No Additional Info: (Thanks for fixing the bug in 5.4.2.0, that made it impossible to work with hi-res images at all). User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36
Created attachment 136896 [details] Very high resolution PNG
I confirm, that LO gets really slow. It requires about 850MB RAM. Version: 6.0.0.0.alpha0+ (x64) Build ID: 465092047d5fa6ec6dd369372e712d76554570ff CPU threads: 4; OS: Windows 6.19; UI render: GL; TinderBox: Win-x86_64@42, Branch:master, Time: 2017-09-26_23:16:01 Locale: de-DE (de_DE); Calc: group
Repro with 4.2.0.4 No repro with Versie 4.0.0.3 (Bouw-id: 7545bee9c2a0782548772a21bc84a9dcc583b89)
No repro with: Versie: 4.1.0.4 Build ID: 89ea49ddacd9aa532507cbf852f2bb22b1ace28
Created attachment 137560 [details] Bibisect log I bisected it on Linux to following commit based on the memory usage commit 2e5167528f7566dd9b000e50fc1610b7bf99132a Author: Armin Le Grand <alg@apache.org> AuthorDate: Thu Oct 31 14:43:21 2013 +0000 Commit: Caolán McNamara <caolanm@redhat.com> CommitDate: Tue Nov 5 15:24:18 2013 +0000 Resolves: #i123500# unified Graphic processing to use GraphicPrimitive2D (cherry picked from commit f5d69b2b8b002ca6905496a9d9065ef76b5641d7)
Adding CC to Armin Le Grand
*** This bug has been marked as a duplicate of bug 80659 ***
Bug 80659 doesn't seem appropriate
*** Bug 104296 has been marked as a duplicate of this bug. ***
Problem is still in present in: Version: 6.1.3.2 (x64) Build ID: 86daf60bf00efa86ad547e59e09d6bb77c699acb CPU tråde: 4; Styresystem: Windows 10.0; Gengiver af brugergrænseflade: Standard; Lokalisering: da-DK (da_DK); Calc: CL
Reasonable speed, but lots of processing in the background while typing (with only the single image around). So still repro: Version: 6.3.0.0.alpha0+ Build ID: 20ea90a557b5bc744fd234e3a20ab1db484cf88b CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-03-22_03:21:58 Locale: nl-NL (nl_NL); UI-Language: en-US Calc: threaded
This is solved with Skia Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: dc3b64dcbfb0a49c0be65bd8d73ed4e6d3828a21 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: nl-NL Calc: CL
(In reply to Telesto from comment #12) > This is solved with Skia > Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community > Build ID: dc3b64dcbfb0a49c0be65bd8d73ed4e6d3828a21 > CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win > Locale: nl-NL (nl_NL); UI: nl-NL > Calc: CL Hi Telesto, What about without SKIA? This bug was reported when SKIA wasn't implemented in LibreOffice
(In reply to Xisco Faulí from comment #13) > (In reply to Telesto from comment #12) > > This is solved with Skia > > Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community > > Build ID: dc3b64dcbfb0a49c0be65bd8d73ed4e6d3828a21 > > CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win > > Locale: nl-NL (nl_NL); UI: nl-NL > > Calc: CL > > Hi Telesto, > What about without SKIA? This bug was reported when SKIA wasn't implemented > in LibreOffice Presumably not, however GDI is pretty much unsupported. Should be phased out eventually (I requested that already, but Luboš Luňák preferred to keep it for a while. So the only thing which remains the Linux backends and MacOS. However I haven't checked my Skia image perf reports against other backends either (which ideally should be done). In my ideal world I prefer one or maybe 2 backends. This would make reporting and fixing less complex. However needs an upfront investment to get Skia on those systems too.. and currently no budget :-(
(In reply to Telesto from comment #14) > (In reply to Xisco Faulí from comment #13) > > (In reply to Telesto from comment #12) > > > This is solved with Skia > > > Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community > > > Build ID: dc3b64dcbfb0a49c0be65bd8d73ed4e6d3828a21 > > > CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win > > > Locale: nl-NL (nl_NL); UI: nl-NL > > > Calc: CL > > > > Hi Telesto, > > What about without SKIA? This bug was reported when SKIA wasn't implemented > > in LibreOffice > > Presumably not, however GDI is pretty much unsupported. Should be phased out > eventually (I requested that already, but Luboš Luňák preferred to keep it > for a while. > > So the only thing which remains the Linux backends and MacOS. However I > haven't checked my Skia image perf reports against other backends either > (which ideally should be done). > > In my ideal world I prefer one or maybe 2 backends. This would make > reporting and fixing less complex. However needs an upfront investment to > get Skia on those systems too.. and currently no budget :-( The question is not about whether it's supported or not, or which one is your preference. I don't think you should close a bug happening in GDI when you are using SKIA because the bug is not about SKIA, it's about GDI. OTOH, if you test it with GDI and the issue is gone, then you can close it.
@Luboš Luňák Any outlook what QA should do with GDI bugs. I assume GDI will be deprecated pretty soon. So if I stubble on a bug. test it, and it's working with Skia, I see no problem anymore, resulting in WFM... but apparently slightly to eagerly (In reply to Xisco Faulí from comment #15) > The question is not about whether it's supported or not, or which one is > your preference. I don't think you should close a bug happening in GDI when > you are using SKIA because the bug is not about SKIA, it's about GDI. OTOH, > if you test it with GDI and the issue is gone, then you can close it.
The way I see it: - GDI is AFAIK practically unmaintained, so it may perhaps get fixes, but unlikely to get improvements, and is possibly to be removed somewhen in the future when Skia is deemed stable and tested enough - this is an improvement, relatively corner case and simple to work around ('Compress..' in the context menu to make the image a reasonable size) - Skia often performs differently from all the other backends (being new, well tested, optimized, whatnot), so GDI bugs should be tested with some non-Skia backend to determine whether they are GDI-only bugs or non-Skia bugs In this specific case I'd assume this is non-Skia, but if it's GDI-only, then it's unlikely to ever get fixed (other than by GDI getting removed).
I do not see any problems in Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 3a61cce54277fd12570103a191c50d9b37ef3dd3 CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: ru-RU Calc: threaded Closed as WFM because LO now uses SKIA by default (and uses Raster mode anyway)