Description: We use our spreadsheets to enter data from ship's logs. The image of the log page is the background for our Log Page sheet. One of our uses reported that the new version of Calc was very slow. I also had the new version of LO, and it was normal. We have several user preferences on the Setup sheet. The log page image was hard to read, and so I turned on the Image Enhancements option in cell C25 of the Setup Sheet. LO immediately slowed to a crawl, to the extent that entering a sequence like 30.12 would take several seconds for the digits to appear. I turned off Image Enhancements, but the problem remained. I closed and reopened the spreadsheet, but the problem remained. I rebooted my PC and the problem remained. I alerted all our users not to update LO and I advised them to check and turn off the Automatic Update option. This is my system: Version: 25.2.1.2 (X86_64) / LibreOffice Community Build ID: d3abf4aee5fd705e4a92bba33a32f40bc4e56f49 CPU threads: 4; OS: Windows 11 X86_64 (10.0 build 22000); UI render: Skia/Raster; VCL: win Locale: en-CA (en_CA); UI: en-US Calc: CL threaded Steps to Reproduce: 1. Open the spreadsheet 2. Enter some data on the Log Page sheet 3. Turn on Image Enhancement on the Setup sheet 4. Enter some date on the Log Page sheet again. Actual Results: 1. With Image Enhancement off, the spreadsheet works normally 2. When Image Enhancement is turned on, the spreadsheet is very slow. Expected Results: The spreadsheet would work at a normal speed irrespective of the state of the Image Enhancement option. Reproducible: Always User Profile Reset: No Additional Info: Version: 25.2.1.2 (X86_64) / LibreOffice Community Build ID: d3abf4aee5fd705e4a92bba33a32f40bc4e56f49 CPU threads: 4; OS: Windows 11 X86_64 (10.0 build 22000); UI render: Skia/Raster; VCL: win Locale: en-CA (en_CA); UI: en-US Calc: CL threaded I tried the spreadsheet after Start in Safe mode. It was OK, but we need our macros to work, so it is not an option.
Created attachment 199631 [details] This spreadsheet gets very slow when Image Enhancement is turned on. Cell C25 on the Setup sheet. This spreadsheet works normally in 25.2.1.2 with Image Enhancement turned off. It gets VERY slow when Image Enhancement is turned on. It worked normally with LO from Versions 3 to 24. Enter some data on the Log Page sheet. Turn on Image Enhancement on the Setup sheet. Enter some data on the Log Page sheet.
One of our users tried our spreadsheet with 25.2.1.2 on Linux. He noted that it was very fast with Image Enhancement turned either on or off. It made no difference. This was his note: I installed 25.2.1.2 on Linux and it is speedy! Going back and forth with enhancement on or off, it is speedy! I tried disabling enhancements and closing the spreadsheet. Then when I opened it again with enhancements still disabled. It was fast. I enabled enhancements, and it was still fast. No matter what I do, 25.2.1.2 is fast on Linux. Faster than 7.6 that I had been using, and faster than the development 25.8.2
I submitted this over a month ago. We are unable to use LibreOffice 25.2 and support of LibreOffice is ending in June. Can anyone look at this, please? I cannot change the severity level to critical, but it should be. Thank you...
It appears like the "Image Enhancements" option has been made by your organization. Your organization knows how it implemented it and can debug it to find the element which causes the performance degradation. When you will provide us steps which can reproduce the issue from a blank file, then we will be able to confirm the issue. Accompanying the steps, upload a file with only the required sheets/macros to reproduce the issue If support is critical to your organization, then you might consider paid support of Libreoffice like Collabora Office For Desktop (https://www.collaboraonline.com/collabora-office/) https://www.libreoffice.org/download/libreoffice-in-business/
If you can't reproduce from a blank file, then you can start from the file you already uploaded as long as you remove all the elements not required to reproduce the issue. But you need to explain your implementation of the image enhancement
The image enhancement options in this spreadsheet are quite straight forward: The user can opt to change the image enhancements on the Setup sheet, turning the enhancements on with Cell C25, and choosing the values in Cells C26-29. From the macro OW/GetImage: If EnhanceFlag = "Y" Then If Brightness <> 0 Then objImage.AdjustLuminance = Brightness If Contrast <> 0 Then objImage.AdjustContrast = Contrast If Gamma <> 0 Then objImage.Gamma = Gamma If ColorMode = "C" Then objImage.GraphicColorMode = com.sun.star.drawing.ColorMode.STANDARD End If If ColorMode = "G" Then objImage.GraphicColorMode = com.sun.star.drawing.ColorMode.GREYS End If End If When this option was turned on in Version 25 with Windows, the spreadsheet became very slow. There was no change in responsiveness for our user who uses Linux.
Using LibreOffice Calc version 24.8, I opened a new spreadsheet, and set one of our images as a background. The speed of response was fast. I downloaded and installed: Version: 25.2.2.2 (X86_64) / LibreOffice Community Build ID: 7370d4be9e3cf6031a51beef54ff3bda878e3fac CPU threads: 4; OS: Windows 11 X86_64 (10.0 build 22000); UI render: Skia/Raster; VCL: win Locale: en-CA (en_CA); UI: en-US Calc: CL threaded I opened the spreadsheet with the image. I changed the Brightness to some other value from zero. Typing data in a cell is painfully slow. I will attach an image to this thread.
Created attachment 200315 [details] This is one of our images that slows Version 25.2 when it is imported into the background. Insert the image into the background of the spreadsheet. Change the brightness. The response with typing or moving around is very slow.
Created attachment 200316 [details] Example file Sample based on comment 8
Slow scrolling with Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7fac8458e35620b9855cc6c68a9675159a849b65 CPU threads: 8; OS: macOS 14.7.4; UI render: Skia/Metal; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded Smooth scrolling with Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 9c1a48f844eaefc505a5914338b6f444011bf315 CPU threads: 8; OS: macOS 14.7.4; UI render: Skia/Metal; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
Created attachment 200317 [details] Example file
Bisection results based on response speed of character input with macros turned off commit 27829e4a6c5a4a1162599550c46b5e7f974aba91 author Armin Le Grand (allotropia) <armin.le.grand.extern@allotropia.de> Wed Jul 10 13:16:20 2024 +0200 CairoSDPR: Improve BColorModified Bitmaps There is the complete BColorModifierStack support for primitives for Bitmaps, e.g. hue/saturation, etc, but it was slow due to not being buffered, so had to be re-created often. I changed this to use the common buffering mechanism to improve this. Up to now a fallback to use the old Graphic manipulators for that purpose was in place since this was faster, but had to be done every time. I have now changed the priority to using the primitive way to handle things, but kept the fallback code - just in case. Note that the new stuff is faster, but even much faster when the bitmap is copied and appears multiple times -> the same buffered instance is used, and SDPRs then use the system-dependent data buffered at that prepared data. Also note that this change does not only speedup CairoSDPR, but all PrimitiveRenderers, including the VCL and Metafile ones. In principle everything that uses BitmapEx::ModifyBitmapEx. Had a 2nd thought: Only the content Bitmap gets changed, so for this case we do not need AssociatedAlpha and watch for it to not have changed. Removed that. Change-Id: I2ee36cc84bdc1c723aa01f872edbfd1f51e11c2d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170305
This issue only occurs when skia is ON.
I have turned off Skia rendering, and the spreadsheet is now usable with version 25.2.2.2. It is not quite as fast as it was with version 24.8, but I can inform our users that they can safely update to the latest version, as long as the Skia rendering is turned off.
(In reply to Saburo from comment #13) > This issue only occurs when skia is ON. When it only happens with Skia on it has nothing to do with CairoSDPR, that is then not used. To make sure you may try to run LO using the 'DISABLE_SYSTEM_DEPENDENT_PRIMITIVE_RENDERER=1' envvar, that forces CairoSDPR to be switched off
I've tried 3 different patterns but they're all slow. 1. pwsh -Command { $env:DISABLE_SYSTEM_DEPENDENT_PRIMITIVE_RENDERER=1; C:\'Program Files'\LibreOffice\program\soffice.exe } 2. C:\Windows\System32\cmd.exe /c "set DISABLE_SYSTEM_DEPENDENT_PRIMITIVE_RENDERER=1 && START /D ^"C:\Program Files\LibreOffice\program^" soffice.exe --norestore" 3. "C:\Program Files\LibreOffice\program\soffice.exe" -env:DISABLE_SYSTEM_DEPENDENT_PRIMITIVE_RENDERER=1
FWIW: I bisected this to the same commit as Saburo in comment 12 with Skia/Raster rendering ON Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: c92e4d1a944019dd5b14cdce3d85213d2a8d9e92 CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL threaded
@Saburo, @Telesto: Thanks for checking. Note that - since there is no cairo and thus no CairoSDPR anyways on windows - using DISABLE_SYSTEM_DEPENDENT_PRIMITIVE_RENDERER makes no difference, I missed that you do that on windows. What I know is that the e.g. color-modified bitmap is now buffered to not have to do that pixel-based manipulations all over again for each paint. CairoSDPR then buffers a cairo-specific form of that one, that makes it fast. Unfortunately the sika impl does not use that same buffer but implemented it's own one, thus it *might* be inefficient there. I was not involved there, so I do not know. GDI Win back-end should use that standard buffering described above, so Q: What about speed on win without Skia (not too sure buit maybe ssth like SAL_USE_VCLPLUGIN=gen)...?
(In reply to Armin Le Grand (allotropia) from comment #18) What about speed on win without Skia (not too sure buit maybe ssth like > SAL_USE_VCLPLUGIN=gen)...? It's fine with Windows GDI rendering
@Noel (In reply to Armin Le Grand (allotropia) from comment #18) > What I know is that the e.g. color-modified bitmap is now buffered to not > have to do that pixel-based manipulations all over again for each paint. > CairoSDPR then buffers a cairo-specific form of that one, that makes it > fast. Unfortunately the sika impl does not use that same buffer but > implemented it's own one, thus it *might* be inefficient there. I was not > involved there, so I do not know. > GDI Win back-end should use that standard buffering described above, so Perhaps idea on the matter? Perf bugs is one of you're specialties. And you're somewhat familiar with Skia code..
@Noel: It's about the bitmap buffered using basegfx::SDD_Type::SDDType_ModifiedBitmapEx in BufferedData_ModifiedBitmapEx - that one seems *not* to be buffered by Skia.. HTH!
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/48c7b7c06b918702eab88b58f05c09a3a4f19928 tdf#165595 speedup drawinglayer processing skia images It will be available in 25.8.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.
Noel Grandin committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/5563780e246e8c0d5896337e3665ee6b3fa37752 tdf#165595 speedup drawinglayer processing skia images It will be available in 25.2.4. 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.
Noel Grandin committed a patch related to this issue. It has been pushed to "libreoffice-25-2-3": https://git.libreoffice.org/core/commit/9fc984e1f1e619dee048d3e7986546af0c9c6c16 tdf#165595 speedup drawinglayer processing skia images It will be available in 25.2.3. 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.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/23e158e4c35a9f548010827adfccccd70d1928f6 tdf#165595 speedup BColorModifier_gamma It will be available in 25.8.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.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/30563605dd78f23cc832c6cd426c0f76576ab47d tdf#165595 no need to call Width/Height on every iteration of loop It will be available in 25.8.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.