Libreoffice Calc rendering very slow on GTK3

[Saverio Miroddi]

I'm on a MATE 20.04 machine, with Nvidia proprietary drivers (for reference, can't use Nouveau, since my machine doesn't boot with it).

Libreoffice Calc renders slow. The delay is very noticeable, even when just typing characters.

If I remove the GTK3 styling (`libreoffice-gtk3` package), then the rendering speed is fine (but of course, the program is unstyled, with some workflow consequences).

I've tried to run on GTK2 (`libreoffice-gtk2` package installed), but I see Calc as unstyled, so it seems it's not actually running on GTK2.

I've also tried to disable HW acceleration, but there is no improvement.

I don't experience this slowness on any other program on my installation.

I've noticed that when there's a delay, the Xorg process CPU occupation skyrockets (depending on how fast I type, it may go even to 100% (single thread)).

I've reproduced the same problem on all the LO versions, from the default (6.4.7) to the latest (7.2).

The kernel version doesn't affect the problem as well (experienced on different 5.x versions).

I've tried a packaged LO (from https://libreoffice.soluzioniopen.com), and it has the same behavior.

I'd be perfectly happy to run on GTK2 as workaround, if that allowed persistent copy/paste :)

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: libreoffice-calc 1:6.4.7-0ubuntu0.20.04.1
ApportVersion: 2.20.11-0ubuntu27.18
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: MATE
Date: Mon Aug 23 15:21:08 2021
InstallationDate: Installed on 2020-07-01 (418 days ago)
InstallationMedia: Ubuntu-MATE 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
SourcePackage: libreoffice
UpgradeStatus: No upgrade log present (probably fresh install)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[hackel (hackel)]

Experiencing similar slowdowns running the LibreOffice 7.2 snap on Ubuntu 21.04. After clicking on a cell, it takes ~1.5 seconds for the display to update and show the cell as highlighted. Text doesn't appear for ~1 second after being typed. All the while the Xorg process is pegged at 100%. Also stuck using Nvidia proprietary drivers on this machine.

[Jean-Pierre van Riel (jpvr)]

Same issue for me using latest stable NVidia drivers on 20.04 with latest 7.2 Libre office snap.

I've noticed that only Calc is affected. Impress and Writer are not affected.

So there must be some calc specific graphics acceleration method causing high CPU rendering load.

Unlike the orig bug report, what worked for me was removing the snap and reverting to old deb `sudo apt install libreoffice` back to 6.4.7.2 non-snap version. No rendering performance issues with the older deb package.

https://ask.libreoffice.org/t/calc-and-writer-ver-7-0-are-extremely-slow/58522/8 mentions trying this which I tried with the 7.2 snap version:

SAL_USE_VCLPLUGIN=gen libreoffice

It seemed to work better but still somewhat slow and not nearly as responsive as the 6.4 deb package.

[ubuntu-user (katian)]

Experiencing similar slowdowns running the LibreOffice 7.2.1.2 snap on Ubuntu 20.04.3

[Saverio Miroddi (64kramsystem)]

I've changed my card to an AMD one.

While it's considerably faster than the Nvidia, it's still slowish, or, to put in another way, considerably slower than the GTK2 counterpart.

Something's broken in the GTK3 support. I reiterate that all the LO builds I've tried have performance issue with GTK3, so it's not an issue with the Ubuntu build.

[Dirk Schulze (disc498)]

I have the same problem, with Calc only, in LibreOffice 7.3.7.2, installed from package libreoffice-calc 1:7.3.7-0ubuntu0.22.04.4
My graphics is an old ingegrated Intel HD (Ironlake), that runs everything else on the system perfectly fine.

Typing short sentences very fast, the display is always one sentence behind. Just holding down one key prints the characters noticably slowly, in blocks of approx. five at a time. At the same time, the XOrg process maxes out the CPU.

Disabling HW accelearation had no effect.
Running without GTK3 (using SAL_USE_VCLPLUGIN=gen), the problem disappears, but the UI looks bad.

[Pavel Rojtberg (rojtberg)]

related upstream bug: https://bugs.documentfoundation.org/show_bug.cgi?id=154602