Bug 152657 - Slower graphical performance and laggy behavior on data entry with large window (GTK)
Summary: Slower graphical performance and laggy behavior on data entry with large wind...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
7.1.0.0.alpha1+
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, perf, regression
Depends on:
Blocks: Calc-Formula-Bar Performance Regressions-weld-InputBar
  Show dependency treegraph
 
Reported: 2022-12-23 15:14 UTC by lp.allard.1
Modified: 2023-09-08 08:29 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Graphical issue occuring when LO is run with "SAL_USE_VCLPLUGIN=gen" (99.64 KB, image/png)
2022-12-23 15:44 UTC, lp.allard.1
Details
Test ODS (31.37 KB, application/vnd.oasis.opendocument.spreadsheet)
2022-12-30 21:16 UTC, lp.allard.1
Details
Lag example (522.93 KB, video/x-matroska)
2022-12-30 21:34 UTC, lp.allard.1
Details
Window size effect on lag (2.37 MB, video/x-matroska)
2022-12-30 21:34 UTC, lp.allard.1
Details
Xorg (36.52 KB, image/png)
2023-01-03 02:05 UTC, lp.allard.1
Details

Note You need to log in before you can comment on or make changes to this bug.
Description lp.allard.1 2022-12-23 15:14:11 UTC
Description:
Due to a plethora of critical bugs in 6.3 I upgraded to 7.4.3.2 from TDF packages on Mint 20.3.  Calc's performance is extremely sub-optimal and I experience heavy lagging and slowlyness while navigating my spreadsheet.  A good example is if I hit the down arrow on my KB to send the cursor down and maintain the key pressed for 10 sec, Calc will continue scrolling down in the sheet for a solid 30 sec after I release the down arrow key indicating extreme system overload and bad responsiveness.  CPU is also maxed out.

Starting LO with "SAL_USE_VCLPLUGIN=gen libreoffice7.4" resolves these issues and performance is pretty much as per previous releases.

I tried disabling antialias, hardware acceleration, OpenCL, multi-threading, etc to no avail.

Steps to Reproduce:
1. Launch Calc
2. Open ODS file
3. Experience extreme performance issues

Actual Results:
See description.

Expected Results:
Native performance


Reproducible: Always


User Profile Reset: Yes

Additional Info:
System:    Kernel: 5.4.0-135-generic x86_64 bits: 64 compiler: gcc v: 9.4.0 Desktop: Xfce 4.16.0 
           tk: Gtk 3.24.20 wm: xfwm4 dm: LightDM Distro: Linux Mint 20.3 Una 
           base: Ubuntu 20.04 focal 
Machine:   Type: Desktop Mobo: ASUSTeK model: M5A97 v: Rev 1.xx serial: <filter> 
           BIOS: American Megatrends v: 1605 date: 10/25/2012 
CPU:       Topology: Quad Core model: AMD Phenom II X4 965 bits: 64 type: MCP arch: K10 rev: 3 
           L2 cache: 2048 KiB 
           flags: lm nx pae sse sse2 sse3 sse4a svm bogomips: 27290 
           Speed: 3400 MHz min/max: 800/3400 MHz Core speeds (MHz): 1: 3400 2: 3400 3: 3400 
           4: 3400 
Graphics:  Device-1: NVIDIA GP108 [GeForce GT 1030] vendor: ASUSTeK driver: nvidia v: 470.161.03 
           bus ID: 01:00.0 chip ID: 10de:1d01 
           Display: x11 server: X.Org 1.20.13 driver: nvidia 
           resolution: 1920x1080~60Hz, 3440x1440~60Hz 
           OpenGL: renderer: NVIDIA GeForce GT 1030/PCIe/SSE2 v: 4.6.0 NVIDIA 470.161.03 
           direct render: Yes
Comment 1 lp.allard.1 2022-12-23 15:40:38 UTC
A word of caution, if the "SAL_USE_....." startup CLI command is used, any formatting done in your file **will be completely borked** when saving the ODS file as I just experienced it (not sure if this deserves another bug ticket or is it normal since LO was started with a non-official command?) Will let the devs answer this.
Comment 2 lp.allard.1 2022-12-23 15:44:14 UTC
Created attachment 184330 [details]
Graphical issue occuring when LO is run with "SAL_USE_VCLPLUGIN=gen"
Comment 3 Stéphane Guillou (stragu) 2022-12-28 23:22:58 UTC
Can you please provide the info copied from Help > About LibreOffice ?
Does this happen with all documents or only specific spreadsheets? Are you able to share an example file here?
Comment 4 lp.allard.1 2022-12-30 21:16:41 UTC
Created attachment 184401 [details]
Test ODS
Comment 5 lp.allard.1 2022-12-30 21:34:24 UTC
Created attachment 184402 [details]
Lag example
Comment 6 lp.allard.1 2022-12-30 21:34:44 UTC
Created attachment 184403 [details]
Window size effect on lag
Comment 7 lp.allard.1 2022-12-30 21:36:56 UTC
Bonjour Stephane,

I attached a sample ODS file (Test ODS) made from scratch because my real life examples contain confidential data and I cannot share them...

The lack of performance on this "test" file is not as bad as with my real files and I believe it is because the amount of formatting and overall file size is very different (the test file has only one tab while my real files have 15 to 20 tabs each, and the file size is 31kb VS 1.5MB for my other files)...

As you asked, I am observing performance issues with new (empty) files but on a lower scale... The more the file grows, the more the performance hit seems to be big.

I also attached a small video showing an example of performance hit while typing text (Lag example).  Please note this "lag" also occurs while typing formulae making it extremely difficult not to make errors......  Keep in mind that the ODS file shown in the video is BLANK and there's a noticeable lag, so imagine with a LARGE spreadsheet where the computers is many seconds behind me when typing...

I made an interesting discovery.  If I make the Calc window pretty small, the performance hit almost disappear. The larger I make the window the more severe the "lag" is (see attachment "Window effect on lag").

Finally as requested, system info:

Version: 7.4.3.2 / LibreOffice Community
Build ID: 1048a8393ae2eeec98dff31b5c133c5f1d08b890
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: en-CA (en_CA.UTF-8); UI: en-US
Calc: CL
Comment 8 lp.allard.1 2022-12-30 21:50:23 UTC
Just closed Calc and noticed this in "dmesg".. Not sure if related or not but former LO versions did not segfault in any way (was very rare):

soffice.bin[24252]: segfault at 7f09207fa780 ip 00007f0957a7b920 sp 00007ffc4517a758 error 4 in libuno_sal.so.3[7f0957a60000+68000]
Comment 9 QA Administrators 2022-12-31 03:19:45 UTC Comment hidden (obsolete)
Comment 10 Stéphane Guillou (stragu) 2023-01-02 13:34:13 UTC
Thank you for the extra info!

Using attachment 184401 [details], I can see the difference in lag on repeated characters between small window and large window. Reproduced since:

Version: 7.1.8.1 / LibreOffice Community
Build ID: e1f30c802c3269a1d052614453f260e49458c82c
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

Also in recent master build:

Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 12e8d57e791bb1befc0716d4d02af7d1d1ccb4ae
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

But not in 7.0:

Version: 7.0.6.2
Build ID: 144abb84a525d8e30c9dbbefa69cbbf2d8d4ae3b
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

-> Regression.

Couldn't reproduce with KF5 VCL.
Comment 11 Stéphane Guillou (stragu) 2023-01-02 17:39:26 UTC
bisected with linux-64-7.1 repo to first bad commit:

commit e087e25f05e689091cbf1c4f91b6e93878ac17ec
author	Caolán McNamara <caolanm@redhat.com>	Mon Oct 05 14:19:05 2020 +0100
committer	Caolán McNamara <caolanm@redhat.com>	Fri Oct 16 12:54:14 2020 +0200
tree 8adb7ccbfa34e45e549a17bd9ee0a85067db1671
parent d6b7cc3f7c07b98c90194e8b33cf44b94804b525

weld InputBar

this also restores that DnD of a selection from the inputbar is pasted as plain
text not rich text formatted with the happenstance formatting of the inputbar's
EditEngine

Change-Id: If4934f83c14357afec2e0a7e1d51c8a1aea1d292
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104037
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>

Caolán, could you please have a look?
Using the attachment, with a fullscreen window and the viewport zoomed out a fair bit, the jumps/lag with a single repeated character is noticeable.
Removing the inputBar with "View > Formula Bar" stops the lag.
Comment 12 lp.allard.1 2023-01-03 02:05:43 UTC
Not sure if relevant but I found out Xorg seems to be the one experiencing the most pain.  When I simply hold a key down and experience the lag, Xorg goes up near to 100% CPU.  Correlation is almost perfect.

Same occurs when navigating a spreadsheet and dragging cells around, doing anything really...

See attachement "Xorg.png"
Comment 13 lp.allard.1 2023-01-03 02:05:55 UTC
Created attachment 184455 [details]
Xorg
Comment 14 lp.allard.1 2023-03-01 12:30:57 UTC
Upgraded to LOO 7.5.0.3 and its even worse.  Now in addition to the previous behavior, I experience extreme lag when entering keystrokes (formulae or just plain text) when the sheet is full screen and contains a high % of contents.  Reverting to LOO 6.0 and MS Office until this is fixed because I can no longer use LOO for my existing spreadsheets.
Comment 15 Caolán McNamara 2023-03-01 20:32:05 UTC
caolanm->stragu: I'm not sure I can see this problem. With attachment 184401 [details] clicking in A150 (default top left cell) and holding down "k" the bibisect builds seem to me as responsive in 7.4 as 7.0. In my dbgutil build there does seem to be a lag when enough "k"s are inserted to go multiline but that could seems to be an artifact of the extra debugging checks and there wasn't mention that the input string has to be crazy long for the effect to be seen.

If you are in a position to build yourself, does commenting outthe cairo_set_operator(cr, CAIRO_OPERATOR_DIFFERENCE) in vcl/headless/CairoCommon.cxx have any effect. There has been pain points in the past with nvidia and some of those OPERATORS.
Comment 16 Stéphane Guillou (stragu) 2023-03-02 07:49:37 UTC
(In reply to Caolán McNamara from comment #15)
> caolanm->stragu: I'm not sure I can see this problem. With attachment 184401 [details]
> [details] clicking in A150 (default top left cell) and holding down "k" the
> bibisect builds seem to me as responsive in 7.4 as 7.0. In my dbgutil build
> there does seem to be a lag when enough "k"s are inserted to go multiline
> but that could seems to be an artifact of the extra debugging checks and
> there wasn't mention that the input string has to be crazy long for the
> effect to be seen.
> 

The difference is a bit subtle for me, but noticeable. I make sure I fullscreen the window, and zoom out a bit to view a large number of cells.
Repeating the character is smooth before the commit, and a bit jumpy after the commit but smooth again if formula bar is hidden.

lp.allard, it would be great if you could confirm that we are seeing the same issue by:
- Testing version 7.0 and verifying that the issue is not there;
- Deactivating the formula bar in View > Formula Bar to see if the performance issue disappears in recent versions.
Comment 17 lp.allard.1 2023-03-02 16:04:05 UTC
OK I've done some testing by performing repeatable actions:

LOO 7.0.0.1
Mouse scrolling (via wheel):  Extremely fast & fluid
Repeated keyboard entry ("aaaaaaaaaa"): Extremely fast & fluid
Moving cursor around:  Extremely fast & fluid
Cross-sectional selection:  Extremely fast & fluid

LOO 7.5.1 - WITH FORMULAE BAR
Mouse scrolling (via wheel):  Extremely Slow
Repeated keyboard entry ("aaaaaaaaaa"): Extremely Slow
Moving cursor around:  Extremely Slow
Cross-sectional selection:  OK (but slower than 7.0.0.1)

LOO 7.5.1 - WITHOUT FORMULAE BAR
Mouse scrolling (via wheel):  Slow
Repeated keyboard entry ("aaaaaaaaaa"): OK (but slower than 7.0.0.1)
Moving cursor around:   OK (but slower than 7.0.0.1)
Cross-sectional selection:   OK (but slower than 7.0.0.1)
Comment 18 lp.allard.1 2023-03-02 16:07:04 UTC
Side question:   I'd reinstall 7.0.0.1 but in the last few months saved most of my files with more recent versions.  Is there backward compatibility and can I risk corrupting the files if I revert back to an older LOO release ?
Comment 19 QA Administrators 2023-03-03 03:25:30 UTC Comment hidden (obsolete)
Comment 20 Stéphane Guillou (stragu) 2023-03-29 14:22:12 UTC
(In reply to Caolán McNamara from comment #15)
> If you are in a position to build yourself, does commenting outthe
> cairo_set_operator(cr, CAIRO_OPERATOR_DIFFERENCE) in
> vcl/headless/CairoCommon.cxx have any effect. There has been pain points in
> the past with nvidia and some of those OPERATORS.

Sorry I missed that last time. I repro without a graphics card, so I assume this wouldn't apply here, right?

lp.allard, thanks for confirming you see something similar, although there might have been another source of slowdown somewhere.
Regarding backward compatibility, developers try to make changes as backward-compatible as possible, so should be OK for your documents but I obviously cant guarantee that at 100%. Backup copies is always a good idea.
Comment 21 lp.allard.1 2023-03-29 15:32:28 UTC
Stephane,  I am not sure what you want me to confirm...  Please specify and I can try to do more testing.

For the BW compatibility, I understand what you're saying, I do keep backups and I confirm that so far, reverting to LO 7.0 didnt cause any issues whatsoever with my documents.

To the actual graphical performance issue of this bug report, I have tried to work with LO DRAW to make a diagram but had to resort to using another application because the performance was simply unbearably bad.  Adding a connector line makes the CPU go to 100% for 10+ seconds each time and only selecting something on the diagram makes the CPU go to 100% for multiple seconds.  I noticed the process X.org is the one using all CPU.

Theres clearly something fundamentally broken between Libreoffice, Nvidia and X-server.

FYI System Specs:

System:    Kernel: 5.4.0-144-generic x86_64 bits: 64 compiler: gcc v: 9.4.0 Desktop: Xfce 4.16.0 
           tk: Gtk 3.24.20 wm: xfwm4 dm: LightDM Distro: Linux Mint 20.3 Una 
           base: Ubuntu 20.04 focal 
CPU:       Topology: Quad Core model: AMD Phenom II X4 965 bits: 64 type: MCP arch: K10 rev: 3 
           L2 cache: 2048 KiB 
           flags: lm nx pae sse sse2 sse3 sse4a svm bogomips: 27292 
           Speed: 3400 MHz min/max: 800/3400 MHz Core speeds (MHz): 1: 3400 2: 3400 3: 3400 
           4: 3400 
Graphics:  Device-1: NVIDIA GP108 [GeForce GT 1030] vendor: ASUSTeK driver: nvidia v: 525.89.02 
           bus ID: 01:00.0 chip ID: 10de:1d01 
           Display: x11 server: X.Org 1.20.13 driver: nvidia 
           resolution: 1920x1080~60Hz, 3440x1440~60Hz 
           OpenGL: renderer: NVIDIA GeForce GT 1030/PCIe/SSE2 v: 4.6.0 NVIDIA 525.89.02 
           direct render: Yes 

FYI NVidia-SMI:

Wed Mar 29 11:29:26 2023       
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 525.89.02    Driver Version: 525.89.02    CUDA Version: 12.0     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|                               |                      |               MIG M. |
|===============================+======================+======================|
|   0  NVIDIA GeForce ...  Off  | 00000000:01:00.0  On |                  N/A |
| N/A   35C    P8    N/A /  30W |    301MiB /  2048MiB |      0%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+
                                                                               
+-----------------------------------------------------------------------------+
| Processes:                                                                  |
|  GPU   GI   CI        PID   Type   Process name                  GPU Memory |
|        ID   ID                                                   Usage      |
|=============================================================================|
|    0   N/A  N/A      2884      G   /usr/lib/xorg/Xorg                218MiB |
|    0   N/A  N/A    572325      G   ...akonadi_archivemail_agent        1MiB |
|    0   N/A  N/A    572339      G   .../akonadi_mailfilter_agent        1MiB |
|    0   N/A  N/A    572345      G   ...n/akonadi_sendlater_agent        1MiB |
|    0   N/A  N/A    572346      G   ...nadi_unifiedmailbox_agent        1MiB |
|    0   N/A  N/A    584096      G   ...464526976390978109,131072       74MiB |
+-----------------------------------------------------------------------------+
Comment 22 q_user 2023-05-04 13:25:02 UTC
FWIW this "100% cpu usage under Xorg" bug is also present on Qubes OS [1], which uses Xen virtual machines with Xorg and no graphical acceleration.
I personally have that problem and it's been reported by other users [2].

Starting in safe mode doesn't help. The only workaround is to use either 'gen' (ugly) or 'kf5' (has a few glitches) instead of the default 'gtk3' vcl plugin.

Reading the comments here and the similar bug reports below, it really seems that there's an issue in how GTK handles acceleration - or lack thereof - in some cases.

- https://bugs.documentfoundation.org/show_bug.cgi?id=144033
- https://bugs.documentfoundation.org/show_bug.cgi?id=145631



[1] https://www.qubes-os.org/
[2] https://forum.qubes-os.org/t/100-cpu-with-every-scroll-in-libreoffice/8027
Comment 23 lp.allard.1 2023-05-04 20:44:27 UTC
You may be on to something.... I recently was using Calc for a small spreadsheet and used the XFCE screenshot tool to insert screengrabs in my spreadsheet.  I've noticed Calc crawls to a halt just scrolling, and the images are having all kind of graphical issues (sometimes they are jumping around, sometimes they disappear and only can I see the border, sometimes a portion becomes transparent, etc).

There's clearly something broken with Nvidia+Xorg+Libreoffice.
Comment 24 M. Knepper 2023-05-18 21:12:01 UTC
Would like to add I notice a single thread/core will jump to 50% or so usage when scrolling on Fedora 38 at 4k. 

When running Debian with i3wm, the same thing happens. It seems to happen regardless of Xorg or Wayland.
Comment 25 lp.allard.1 2023-09-07 15:45:14 UTC
Small update for this issue:  Since the Nvidia driver got upgraded to 525.125.06, the lag became unbearable to a point where even running 7.0 (which didnt lag as much) is no longer possible.  I have upgrade LO to 7.6.0.3 thinking it may help but its worst.

Sadly I have reverted to MS office until a solution is found because its almost unusable for me.