Description: When you import a complex svg file, writer slows very much. It is quite not possible to use it. Steps to Reproduce: 1.get a complex svg file like https://openclipart.org/detail/178295/ddr-ram-memory 2. insert as an image 3. boom ! Actual Results: I have test with and without OpenGL. And I have reset my profile. Same result. Expected Results: Reactive writer as usually. Reproducible: Always User Profile Reset: Yes Additional Info: Version: 7.2.5.2 / LibreOffice Community Build ID: 499f9727c189e6ef3471021d6132d4c694f357e5 CPU threads: 4; OS: Linux 5.13; UI render: default; VCL: gtk3 Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded
no problem in Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 1be170d0629cf761f0ee4173007a3c021966546e CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL nor in Version: 7.2.0.4 (x64) / LibreOffice Community Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b 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 Linux or Gtk3 only?
I don't reproduce with kf5, but gtk3 is definitely slow and gen also shows some slowness. Arch Linux 64-bit Version: 7.2.5.2.0+ / LibreOffice Community Build ID: 20(Build:2) CPU threads: 8; OS: Linux 5.16; UI render: default; VCL: gtk3 Locale: fi-FI (fi_FI.UTF-8); UI: en-US 7.2.5-4 Calc: threaded Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: bf883027ee62ece0844730572305094f53daa521 CPU threads: 8; OS: Linux 5.16; UI render: default; VCL: gtk3 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded
Created attachment 177726 [details] SVG file for testing Already slow in oldest of Linux 6.3 bibisect repo
This one seems OK to me, but please take a look at bug 146319
(In reply to Hossein from comment #4) > This one seems OK to me, but please take a look at bug 146319 In the chat it came up that Hossein was testing loading. He confirms slowness in scrolling.
Would it be relevant here to extend the slowness issue to editing the SVG in Draw? This would tie in to the problems I've been having on macOS, where doing anything to a relatively complex SVG file is an exercise in frustration, as LO is too slow to respond to be useful (whether zooming in on a part of the image, editing nodes, object properties, copy/pasting objects, etc). I used to use LO4.1 to do the editing because of the slowness of current releases, but now I can't even do that on Arm silicon as LO4.1 won't even start. As buovjaga has reported in #c3, I first noticed the beginning of the slowdown in 6.3.x.
(In reply to Alex Thurgood from comment #6) > Would it be relevant here to extend the slowness issue to editing the SVG in > Draw? > > This would tie in to the problems I've been having on macOS, where doing > anything to a relatively complex SVG file is an exercise in frustration, as > LO is too slow to respond to be useful (whether zooming in on a part of the > image, editing nodes, object properties, copy/pasting objects, etc). I used > to use LO4.1 to do the editing because of the slowness of current releases, > but now I can't even do that on Arm silicon as LO4.1 won't even start. > > As buovjaga has reported in #c3, I first noticed the beginning of the > slowdown in 6.3.x. Then it sounds like a different issue, because I saw it in the oldest of 6.3 (because that is the oldest repo on my main machine), while you saw it *appear* in 6.3. This means 146779 was already in 6.2 while the regression you saw is newer. You also talk of editing nodes in Draw while this one is about inserting it as an image in Writer.
The performance seems pretty variable depending on backends. With gtk+wayland it's not bad for me, with x11 its not great but ok. Stock gen seems a little slow, but with skia its slowest I find. The copies that VclProcessor2D::RenderMaskPrimitive2DPixel does seem to be the bottleneck. That method has been indicated before with tdf#140797 If I force the Clipping route even for non-rectangles, then this example works performs well for me
The Skia case is slow only with Vulkan. The comes from https://cgit.freedesktop.org/libreoffice/core/commit/?id=8ca549ebc01a7aa0b288c521a9e60e76f4d8e97d (the Cairo commit is https://cgit.freedesktop.org/libreoffice/core/commit/?id=cf9be3417bc2be5f772c03180b7cbd248b82cad5). What seems to happen is that impBufferDevice tries to copy a small part of a GPU-based image to a raster-based image because of that commit, and that causes fetching of GPU data in this case. So basically a pick-your-poison situation, as long as we have to deal with the split alpha hack.
Or I guess I can come up with a hack for a hack *sigh* https://gerrit.libreoffice.org/c/core/+/141211 .
Slow in scrolling in Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: dabedcaf27b0af1e38a611b8d8e48444f848e01d CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded