I’ve seen the same issue on my T430 when the GTK3 flavor with R4.1 is used. Switching to Generic of KF5 (KDE) flavor fixes the issue. I can also confirm that this issue only exists on R4.1. I’ve used debian-11-minimal in both scenario (R4.0 / R4.1)
I’m still using R4.0 after downgrading a few months ago in the context of freezes and crashes. The experience of R4.0 on my T430 is so much better that I feel a strong inertia to try to go back up to R4.1 although I know I have to eventually.
Yet another reason for switching to KDE, and explanation for why I
have no reports.
@phl - thanks for your description of the problem.
Well, “throw more resources” is usually the easy fix 
I also thought LO’s sluggishness would be mitigated by my higher-spec hardware but LO with the default gtk ui is still unusable.
I assume you’re still using up-to-date templates with the latest version of LO? If so that would be interesting to find out what the differences are between identical/similar versions of LO and R4.0 vs R4.1.
Care to share your LO version, template OS, and the output of glxinfo -B (both in dom0 and your appvm)?
I understand, but I’d expect that users comfortable enough to switch to KDE would probably have found the KF5 workaround; and switching to KDE just because of LO seems a bit too much (to be fair to GTK I don’t have any other issues).
Also, on my setup KF5 is much better but not without glitches; the screenshot below shows the truncated text bar, making it impossible to type complicated formulas without “enlarging” the bar with the button on the right (not displayed on the pic), which uses quite a lot of vertical screen estate.
(probably because of some dpi stuff - but then I’ll have to debug KDE and dpi/scaling 
)
I was being facetious, although my second point stands.
Version: 7.0.4.2
Debian package version: 1:7.0.4-4+deb11u6
Debian 11 “bullseye” (minimal)
[user@dom0 ~]$ glxinfo -B
name of display: :0.0
display: :0 screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Intel Open Source Technology Center (0x8086)
Device: Mesa DRI Intel(R) Ivybridge Mobile (0x166)
Version: 17.0.5
Accelerated: yes
Video memory: 1536MB
Unified memory: yes
Preferred profile: core (0x1)
Max core profile version: 3.3
Max compat profile version: 3.0
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.0
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile
OpenGL core profile version string: 3.3 (Core Profile) Mesa 17.0.5
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL version string: 3.0 Mesa 17.0.5
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 17.0.5
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
user@offline:~$ glxinfo -B
name of display: :0
display: :0 screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Mesa/X.org (0xffffffff)
Device: llvmpipe (LLVM 11.0.1, 256 bits) (0xffffffff)
Version: 20.3.5
Accelerated: no
Video memory: 953MB
Unified memory: no
Preferred profile: core (0x1)
Max core profile version: 4.5
Max compat profile version: 3.1
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.2
OpenGL vendor string: Mesa/X.org
OpenGL renderer string: llvmpipe (LLVM 11.0.1, 256 bits)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 20.3.5
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL version string: 3.1 Mesa 20.3.5
OpenGL shading language version string: 1.40
OpenGL context flags: (none)
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 20.3.5
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
HTH
You don’t need to switch to KDE just to use the KDE flavor of LO.
Just make sure libreoffice-gnome and libreoffice-gtk3 are NOT installed and libreoffice-kf5 is installed. It will pull in all necessary dependencies.
You can additionally define SAL_USE_VCLPLUGIN=kf5
(the package names above work on Debian, I trust you can find the Fedora equivalent on your own)
@Sven - thanks.
I did more tests with various Mesa and LO versions. Mesa doesn’t seem to be the culprit: with the gtk3 VCL plugin, LO v7.0.4.2 doesn’t lag on R4.1 on debian-11 and debian-12; but v7.3.7.2 is unusable on f36 (and f37, and debian-12 with the debian’s LO debs, and debian-12 with LO debs, etc.).
→ will need to bisect LO versions to see which one introduced the issue.
[edit: the bug was introduced in 7.1.0.0.alpha1 ; 7.0.6.2, the previous version, is OK.]
[edit2 / 2023-05-15: bug filed: 155326 – Calc with gtk3 VCL is unusable with large spreadsheets: huge lag, high CPU usage, etc.]
[edit3 / 2023-06-07: found the commit that introduced the issue - comment]
The main differences between R4.0 and R4.1 are Mesa versions: 17x vs 20x on dom0, while debian stable is on 20.x and fedora 37 on 23.x.
On my T450s with R4.1 I have accelerated graphics, but on my 13th gen hw R4.1 isn’t recent enough so no acceleration yet (=llvmpipe). Mind you, I just found this out and hadn’t even noticed any lag.
That would rule out acceleration in dom0 as a contributing factor to LO’s high CPU usage with VCL=gtk3.
Comparing templates:
on debian-11 minimal template, apt install libreoffice-calc mesa-utils.
→ LO uses the x11 VCL by default (same as SAL_USE_VCLPLUGIN=gen) so it’s blazing fast.
then, apt install libreoffice-gtk3=1:7.0.4-4+deb11u6.
→ LO was a bit slower than x11/gen but still much, much faster than LO on my f37 template: scrolling stopped immediately after releasing arrow keys, while on f37 scrolling went on for at least a few seconds.
OK - so debian-11 with LO 7.0.4.2 works on R4.1 whatever the VCL plugin.
Same test as above with a debian-12 ITL testing template (shipping with mesa: 22.x): LO is unusable, like in f36/f37 templates.
But LO version in debian-11 is 7.0.4.2; in f37 it’s 7.4.6.2; in debian-12 it’s 7.4.5.1.
Could it be that LO official releases (/debs) work while distro-packaged ones dont?
→ install libreoffice 7.0.4.2 from LO’s archive debs on debian-12: no lag.
→ install libreoffice 7.4.5.1. from LO’s archive debs on debian-12: lag.
So, it’s not an issue with distribution packages; LO seems to have introduced the bug somewhere between those versions.
For the record the LO commit that introduced the 100% CPU usage is identified (see bug link above), but despite the work/time I’ve spent debugging this the LO dev who asked me to bibisect/find the issue is MIA and/or not interested, with no reply since the end of June. I’ll ping him a last time before creating a Qubes issue asking the fedora template maintainer to consider including the qt5 fix (BTW one of the last qt5 updates fixed the graphical glitch I had with the truncated formula bar, so it’s now a 100% perfect replacement to gtk). As mentioned elsewhere, a lot more qubes users are likely to encounter the slow LO bug after the debian template is upgraded to 12 (as debian 11 has a pre-bug version of LO).
Okay I’m a bit lost here. Is there any known way to set the environment variable so that it also works when starting LO through Nautilus?
I would assume this is how most users use LO: by opening existing files they want to edit.
Thanks @taradiddles for your time on investigating this issue. Let’s hope we will soon see a fix upstream (although there still is no response in the bugreport since July as far as I saw :/).
“SAL_USE_VCLPLUGIN=gen libreoffice” does not improve anything for me. The whole interface becomes kind of choppy.
With libreoffice-kf5 (coming with its 200 MiB of dependencies) + SAL_USE_VCLPLUGIN=kf5 things are just a little better compared to libreoffice-gtk3. Still lagging when scrolling.
I hope someone can suggest a better solution (if one exists).
On debian-12 I could also force skia sofware rendering in the libreoffice options (Tools → Options --View → below the option to disable hardware acceleration). Apart from removing the libreoffice-gtk3 package that improved performance as well.
I needed to enable font antialiasing though to make it bearable.
Just a heads up, running fresh new installed 4.2, with the new fedora templates.
Doubt this has anything to do with above tweaks but just experienced that adding a sheet/tab to my calc ods file and saving it a few times during updates resulted in today having lost all the work.
I usually >90% of the times don’t close the calc sheet and just shut down the AppVM, this was never a problem before and i explicitly remember having done a save after last changes.
This is a first for me in a decade of using LO.
The ods file only kept the changes right before i added the new tab/sheet to it.
i couldn’t say at this moment, just know that i saved a bunch of times and this has never happened before in all the years.
The only other thing that come to mind is the quit old nvme drive and/or some sync didn’t happen, which is also weird since i was working and saving for Hours in that sheet but Hours of work are lost.
Everything before i added that additional tab / sheet was saved though.
This sounds off-topic.
Data loss != slow scrolling
You really need to read my first post, especially the start of the second sentence.
To make you understand why i posted this here:
When changing something on a System and then suddenly observe odd behavior wouldn’t the place to post be where you picked the changes from?
You really need to read my first post, especially the start of the second sentence.
It says you doubt it is related to the tweaks above but it doesn’t clarify:
Without that info, I can’t relate the unfortunate data loss you experienced to the current topic.
Moderation note: edited inappropriate content away.
The steps i took:
sudo dnf remove libreoffice-gnome libreoffice-gtk3 && sudo dnf install libreoffice-kf5
sudo /etc/profile.d/libreoffice.sh
export SAL_USE_VCLPLUGIN=kf5
sudo nano /usr/bin/soffice
…
export SAL_USE_VCLPLUGIN=kf5
# oosplash does the rest: forcing pages in, javaldx etc. are
exec $RRCHECK $VALGRINDCHECK $STRACECHECK “$sd_prog/oosplash” “$@”
After this post i am unfortunately done replying to anything coming from you.
Hi everyone. Is there still only a temporary fix or why did the qubes os team not prioritize this bug and fixed within the last two years? Libreoffice is the most impotant software for me and it is still very slow.
Is this still considered the best solution at the moment? Making LibreOffice run at an acceptable speed under Qubes OS — Rudd-O.com
Thank you for qubes os! It is great to feel save, but this bug is really annoying.
As far as I understood this thread and especially this comment the issue is in LibreOffice itself and can therefore not be fixed in Qubes.
It is possible to mitigate the issue as described in various posts and the blog post you mentioned but as asked here and earlier here, at least for me it remains unclear if this really fixes all use-cases.