Description: Zoom in/out on a document with picture slow with Raster & GDI (fine with Vulkan) Steps to Reproduce: 1. Open attachment 137759 [details] 2. Zoom in/out with CTRL+Scroll wheel Actual Results: Sloooow Expected Results: Bit faster Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.0.0.alpha0+ (x64) Build ID: 6640d7f405d2970ba2825a9455926cc803284d01 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
It was surely better with 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
Created attachment 164851 [details] Bibisect log Bisected to: author Luboš Luňák <l.lunak@collabora.com> 2020-07-27 14:42:15 +0200 committer Luboš Luňák <l.lunak@collabora.com> 2020-07-27 15:57:33 +0200 commit 4addedabe6778e70754709290502d721cdef796d (patch) tree 560d6f7615ed38309e2b93e50c969311dfe9e716 parent 843eb355cb960413fef3817b9cbff75ac1f72c7d (diff) tweak not caching images in Skia drawing when upscaling (tdf#132438) The change done for tdf#134237 was meant to avoid caching of very large images when zooming in. But it turns out that it happens quite often that we get asked to draw something larger than the drawing area, such as when scrolling a document with a larger image. So tweak the check to hopefully avoid only huge images or when upscaling a lot. https://cgit.freedesktop.org/libreoffice/core/commit/?id=4addedabe6778e70754709290502d721cdef796d
Want to bring a Kohei presentation to mind. Especially sheet 26 https://www.slideshare.net/kohei101/life-after-calc-core-change The whole approach is currently annoying frustrating, straining, tiresome.. 1) From user perspective quality wise; brokenness not great 2) From user perspective, reporting bugs and bugs over in over in the same area. 3) From QA perspective, having to confirm/bibisect those bugs 4) From developer perspective, being hunted by those fall out after the fact Not the only one I'm asking/ begging to do this more often. See for example bug 134213 comment 57 It was broken, got fixed, now it's broken again. And if IIRC there was another case where this happened.. And i'm pretty certain this will happen again.. As zooming/scrolling/images being quite cause of problems (in my experience)
(In reply to Telesto from comment #3) > Want to bring a Kohei presentation to mind. Especially sheet 26 > https://www.slideshare.net/kohei101/life-after-calc-core-change If you know how to easily write a unit test checking for unforeseen performance regression with a rather corner-case document, I'm all ears.
*** Bug 136381 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/717ce6838b7ef0add1f9a9655e2b8c0bf60203f0 avoid temporary SkImage when merging bitmaps in Skia (tdf#136244) 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.
Luboš Luňák committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a8a7df6de6b48a03589ac9b66b490875eab19b75 increase Skia image cache size to 64MiB (tdf#136244) 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.
Luboš Luňák committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/93a7f074d3bdcb293fe2e6410c0401056f6c860f tweak not caching overly large Skia images (tdf#136244) 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.
Created attachment 165407 [details] video See the video NOT very fast in Version: 7.1.0.0.alpha0+ Build ID: 3a22f5a589e822e7ca8bbb00e38a3aff93ed7ba5 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-US (ro_RO.UTF-8); UI: en-US Calc: threaded Much more faster in Version: 7.0.1.2 Build ID: 7cbcfc562f6eb6708b5ff7d7397325de9e764452 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-US (ro_RO.UTF-8); UI: en-US Calc: threaded
(In reply to BogdanB from comment #9) > Created attachment 165407 [details] > video > > See the video > > NOT very fast in > Version: 7.1.0.0.alpha0+ > Build ID: 3a22f5a589e822e7ca8bbb00e38a3aff93ed7ba5 > CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 This bugreport is about the Skia renderer, you use gtk3. Please file a new bugreport for gtk3.
(In reply to Commit Notification from comment #7) > Luboš Luňák committed a patch related to this issue. > It has been pushed to "master": > > https://git.libreoffice.org/core/commit/ > a8a7df6de6b48a03589ac9b66b490875eab19b75 > > increase Skia image cache size to 64MiB (tdf#136244) Can we get this number made available to users to modify, or decided as a function of available RAM on the machine? Previous versions of libreoffice had an image cache size option. 64MB appears too small to handle multiple 4Kx4K raster images pasted onto pages without huge slowdowns. This is a regression over libreoffice 6.
(In reply to Frank Ch. Eigler from comment #11) > Can we get this number made available to users to modify, or decided as a There is now org.openoffice.Office.Common.Cache.Skia.ImageCacheSize in the expert settings.