100% cpu with every scroll in LibreOffice

Works much better if you turn GPU acceleration off everywhere. Should be like that out of the box I think.

Could you tell where exactly I should turn it off?

It is deep down in menus, so there is a hack: “libreoffice --safe-mode” , and there is configure option to disable all accelerations. Please share your experience if it did help. I would say we should have this setting pre-configured in all templates.

I’m having the same problem. When disabling all acceleration as suggested it gets slightly better, but still unusable:
Xorg is closing in at 100% CPU consumption with a blank document and just a little scrolling.

This is on Qubes 4.1, Debian-11 and (which may make the difference) running a 5k display. However, this is decent hardware (NUC with 11th Gen i7, 32GB RAM, Iris Xe). On my old 4th Gen i5 with Ubuntu on it everything is super-fast.

1 Like

Hm, 5k display, it is what is was worrying about – if Qubes will handle it well (thinking about hw upgrade and 5k2k)

Internal full HD display here, also got only slightly better.

There is a (temporary) fix: use “SAL_USE_VCLPLUGIN=gen libreoffice” to start libreoffice (make sure that no other libreoffice-process is already running). Then, libreoffice looks ugly but works without increased cpu usage of xorg.

To add more information: I do have the exact same problem in Debian 11 (Libreoffice 7.1.x) as well as Fedora 34 (Libreoffice 7.2.x): xorg cpu usage goes up to 100% if any action is done within libreoffice in Qubes 4.1.

Special case: open an empty libreoffice-calc document. Select any empty cell: everything runs smooth. Input a simple formula (i.e. “=1+2”) in a cell. Selecting this very cell has a lag and 100% cpu usage in the xorg process do occur.

This behaviour started some weeks ago and was not the case about 2 months ago, even in qubes 4.1. So some update has to be the culprit. Unfortunately, I do not have any good solution other than setting the ugly generic VCLPLUGIN.

5 Likes

Looks like it worked!
So it set an environment variable to the value “gen libreoffice”?.. Just curious what it does.

It runs libreoffice with the SAL_USE_VCLPLUGIN environment variable set to value gen. Apparently this tells the libreoffice Visual Class Library to select a plugin named gen (as opposed to, say, gtk3 or qt5). It is likely that the Gtk plugin wants to use OpenGL, which ends up being software-rendered.

I thought maybe instead of switching off Gtk we can disable the attempt to use OpenGL, eg. with GDK_DEBUG=nogl instead. But a quick test (20 pages of lorem ipsum) does not show any difference in a Debian 10 qube (even with SAL_USE_VCLPLUGIN=gen)

1 Like

Sorry to horn in but, have you checked into this libreoffice variable then (SAL_NOOPENGL)? Just to see what it changes. I see that this was used by the previous incarnation of libreoffice (openoffice) but perhaps it didn’t make the cut when they switched names.

https://wiki.openoffice.org/wiki/Environment_Variables

1 Like

Yep, unfortunately “GDK_DEBUG=nogl” does not help. Disabling hardware-acceleration and/or anti-aliasing in the options menus does not help either like SAL_NOOPENGL. The only fix seems to be “SAL_USE_VCLPLUGIN=gen”

FYI: if you uninstall the package “libreoffice-gtk3” in your template VM, you basically have the same effect as “SAL_USE_VCLPLUGIN=gen libreoffice” in every AppVM.

Tnx to a colleague of mine who found out that using QT/KDE as VCLPLUGIN solves the issue even better (looking). Thus, do the following:

  1. dnf remove libreoffice-gtk3
  2. dnf install libreoffice-kf5
  3. export SAL_USE_VCLPLUGIN=kf5

To make that change permanent, do it in your TemplateVM and put the export from step 3 into /etc/profile.d/libreoffice.sh

8 Likes

This works great when launching libreoffice from terminal / launcher, however when opening a file directly within nautilus, that env is never picked up and you get the “basic” UI. I’ve tried setting that env in many places that could be read, but so far I didn’t find any file located outside $HOME (so all appvms based on this template get to work without further changes) that could make it work.

Only workaround I found is to place the env directly at libreoffice executable, with the downside that once the file is replaced due to an update you’d need to change it again, but so far is the only one to make it work in all places (terminal/launcher/nautilus)

/usr/bin/soffice

put the export just before the last exec line

export SAL_USE_VCLPLUGIN=kf5

# oosplash does the rest: forcing pages in, javaldx etc. are
exec $RRCHECK $VALGRINDCHECK $STRACECHECK "$sd_prog/oosplash" "$@"

related:
https://bbs.archlinux.org/viewtopic.php?id=213807

3 Likes

I have the exact same problem. WTF! It’s unusable! (Recently updated to Q4.1 and I can’t use any office apps anymore).

1 Like

Although I would never put it past LibreOffice to be slow, if it’s worse after 4.1 upgrade you might want to make sure you’re not hitting the CPU frequency detection bug (adding xen-acpi-processor kernel module is the remediation if you are).

2 Likes

The variables defined in /etc/environment.d files aren’t visible by Qubes VMs (as verified via both an open terminal and a qvm-run -p). This is despite the fact that systemctl --user show-environment does show the variables as defined. What’s so broken?

Ah, ****! It looks like programs started via the qrexec mechanism don’t get any of the systemd session variables! How is this possible?

Yeah it looks like the qrexec-fork-server totally bypasses the requested user’s session and does its own thing. Why would it do that?

EDIT: Nothing here processes user session environment variables either:

Sigh.

EDIT 2: from the frustration comes the fix:

3 Likes

I work 3 days per month in LibreOffice Calc. This time was the first time (first day in Calc) on Qubes. It was soo slow. 3 seconds each time I clicked somewhere. I hope this will be addressed and resolved soon by the Qubes team.

2 Likes