100% cpu with every scroll in LibreOffice

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

Unfortunately the proposed solution is not satisfactory (Qubes 4.1 Fedora 34). I just noticed that there is a new Fedora template (Fedora 35). I am going tol test LibreOffice with Fedora 35 and report back.

1 Like

LibreOffice is still lagging on Fedora 35 template and it is not possible to work reasonably with it.

Could you please suggest any alternatives for Fedora and point to a installation guide?

Thank you.

1 Like

Try OnlyOffice.

There isn’t a repo for Fedora but you can download the AppImage in your AppVM.

If you want to add it to the Qubes Appmenu, follow this post:

1 Like

Thank you. Just to be sure: Is my assumption correct that you mean downloading and installing the AppImage in the TemplateVM? Only then can I use it permanently in the AppVM from my understanding.

No. the AppImage doesn’t require installation.

You can download it in any dispvm (if you want to keep your office-vm offline), then move it anywhere persistent in the AppVM, like /home/user or /rw.

If you want, you can move the AppImage to the TemplateVM, but place it in /etc/skel. This way, it’ll be placed in the home directory of every new AppVM created from this template.

Make sure you run chmod +x /PATH/TO/AppImage in order to make it executable. Then you can launch it from terminal or with an app shortcut like a mentioned before.

3 Likes

Thank you very much for the explanation.

I have tested LibreOffice again on Fedora 35 AppVM and I found out it depends on the display settings. It is just very slow over a 4k monitor. I don’t know if this problem can be solved easily, but all other applications run smoothly on 4k.

1 Like

I’ll get rid of my 4k monitor. Thanks…

After uninstalling the libreoffice-gtk3 package libreoffice runs faster, without lags, but the font in the app gui interface is very very small. This applies to vm based on debian 11 and fedora 36. My monitor has a resolution of 1920x1080.

How did you deal with this?

In libreoffice there is currently no way to change the font size in menus etc.

1 Like

Here is the real fix. Put this in /etc/profile.d/libreoffice_kf5.sh in your template qube:

export SAL_USE_VCLPLUGIN=kf5

Then install the following package in your template qube:

dnf install -y libreoffice-kf5

Stop your template qube and your application qube. Start your application qube and open up LibreOffice. It should run almost as fast as it used to.

Writeup is also here:

Does this now work reliably even when starting from within Nautilus (see 100% cpu with every scroll in LibreOffice - #29 by equbes)?

I also see that discussion in Make qubes-session inherit the systemd user session variables. by Rudd-O · Pull Request #151 · QubesOS/qubes-gui-agent-linux · GitHub resulted in you blogging about /etc/environment.d. How is this different from what you just recommended @Rudd-O?

Works great if you start libreoffice first. Starting from nautilus results in super-slow performance.

[I know I’m resurrecting an old post :slightly_smiling_face:]

It’s interesting that only a few people complained about that issue as it really prevents working with LO with the GTK3 VCL plugin. Or maybe everybody found this post and is using the ‘gen’ or ‘kf5’ workaround?

Anyway - comment added to a similar LO bug report:

https://bugs.documentfoundation.org/show_bug.cgi?id=152657

Necrophile.

It’s also possible that the few complainers represented the few people
affected by this issue.
Very often I see people complaining that “Qubes is broken” or “This
doesn’t work”. A moments thought would tell them that theirs is not a
general issue, and is likely specific to their hardware of software
configuration.
Of course, there are bugs that affect everyone, and some of them may
have been lurking unnoticed for a long time. Such is life.

I never presume to speak for the Qubes team. When I comment in the Forum or in the mailing lists I speak for myself.
2 Likes

Necrophile

let’s say I’m avoiding duplication :slightly_smiling_face:

It’s also possible that the few complainers represented the few people
affected by this issue

Well, I remember having that issue after upgrading to 4.1 (or was it 4.0? - time is flying). That was with a Thinkpad T450s then. I recently bought a desktop PC: totally different hardware, clean 4.1.2 install, same issue, same workaround. Coincidence? Given that the LO bug seems to be related to GPU (lack of?) acceleration, I’d have expected all Qubes OS users to be affected - yet there aren’t many complaints.
It’s very well possible that only a subset of users open “larger/heavier” spreadsheets where the problem is really noticeable - but it’s also possible that only a few people are hit by this bug, in which case it would be helpful to understand what causes it and find a solution, not a workaround. The goal here is that new Qubes OS users don’t simply complain that “Qubes is broken”.

So - do you use LO, and if so do you have that issue? (as said it takes a pretty large/heavy spreadsheet to notice the problem).

1 Like

I do use LO occasionally and have never encountered this.
I have asked among users I know who do substantial work with
spreadsheets, and they don’t recognise the problem.
I suspect this is another case where more detail from the reporters
would be helpful in determining the causes - I haven’t checked the thread
to see if that information was provided.
I should say that one persons work round is another person’s solution.

I never presume to speak for the Qubes team. When I comment in the Forum or in the mailing lists I speak for myself.

As discussed in other places in this forum, we are using Qubes as our main OS at work (currently about 10 people).

With a slowly but steadily growing team we recently started to have our first Qubes user with little tech experience. She is working mainly on accounting tasks. As these rely on LO spreadsheets, we stumbled upon this issue after a while.

The thing is: Qubes is that different from the accustomed “regular computer” user experience for her that she didn’t bring up this issue on her own. Instead, it became apparent only when others were sitting with her at her desk, realising that LO was “very slow” or even “unusable” (depending on one’s own expectations/experiences/tolerance).

I think lots of hiccups or smaller issues can be hidden underneath this layer of “I know Qubes is different and I don’t expect it to behave as I am used to”. Nevertheless, they are bugs that can be tackled to improve the Qubes user experience.

In this particular case, the problem became visible after changing from a Qubes 4.0 installation to Qubes 4.1 (no upgrade, but a clean reinstall with restored AppVMs if I am not mistaken), both on an older, (but by no means ancient or computationally weak) ThinkPad T450.

The “quick fix” for us was to upgrade her hardware to a T470 with a quad core CPU. Currently, this works much smoother but I guess the underlying issue still exists. We are understaffed in IT Support personnel and have not yet found the time to debug this further. She reports that the new hardware is “much better”.

It seems that short tests with LO spreadsheets on other systems indicate similar behaviour across all devices: the Qubes 4.1 installations are much slower and show the same 100% Xorg CPU usage effect. All devices are ThinkPads, but across multiple generations (T450, T470, T490).

I don’t know if this is a point in favor of this being a more widespread issue because of our homogeneous hardware, but then again ThinkPads are quite common among Linux (and Qubes) users.

2 Likes

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.