Bug 1303562 - libreoffice terribly slow to repaint window contents
libreoffice terribly slow to repaint window contents
Product: Fedora
Classification: Fedora
Component: libreoffice (Show other bugs)
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Caolan McNamara
Fedora Extras Quality Assurance
: 1372334 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2016-02-01 05:04 EST by Peter Zelezny
Modified: 2016-11-29 06:26 EST (History)
17 users (show)

See Also:
Fixed In Version: libreoffice-
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-09-10 01:21:05 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Peter Zelezny 2016-02-01 05:04:19 EST
Description of problem:
libreoffice (calc, writer tested so far) is terribly slow to repaint its windows. It is many times slower than the Fedora 22 version, on the same hardware.

Version-Release number of selected component (if applicable):

How reproducible:
Every time.

Steps to Reproduce:
1. Run libreoffice calc
2. Try to scroll a modest size spreadsheet (2-3 pages) with the mouse scroll-wheel.
3. pain :(

Actual results:
It is very slow to re-paint its window contents

Expected results:
Much faster, as with version included in Fedora 22.

Additional info:
I suppose this is easy to reproduce, but if not, I could provide a video to demonstrate the issue. The installation of Fedora was also upgraded from 22 (not a fresh install).
Comment 1 Ilja Sekler 2016-02-05 04:57:42 EST
Maybe it is worth mentioning that this major performance regression happened when Fedora upgraded LibreOffice from 4.4 to 5.0 and that the LibreOffice build distributed by libreoffice.org is not affected.
Comment 2 p1mail2015 2016-02-08 06:17:25 EST
It is something with on Linux!

Following test with on Linux and Win10:
- new empty Calc sheet.
- write 12345 in cell A1.
- Copy cell A1 into cells A2:M300.
- Drag scroll-bar to top.
On linux it takes 12 seconds before the repaint is done (going from row 300 to 1)!
On VirtualBox with Windows 10 it is instant. Repainting follow scrolling exactly.

i7-4770K, 16GB
Nvidia GeForec GT640.
Nvidia driver 352.63, 4K res

For the record, renaming ~/.config/libreoffice makes no difference...
Comment 3 p1mail2015 2016-02-08 06:23:10 EST
Forgot to mention that it is MATE desktop...
Comment 4 Ilja Sekler 2016-02-08 10:59:23 EST
(In reply to p1mail2015 from comment #2)

> Following test with on Linux and Win10:
> - new empty Calc sheet.
> - write 12345 in cell A1.
> - Copy cell A1 into cells A2:M300.
> - Drag scroll-bar to top.
> On linux it takes 12 seconds before the repaint is done (going from row 300
> to 1)!
> On VirtualBox with Windows 10 it is instant. Repainting follow scrolling
> exactly.

It is not "on Linux". It is just the broken LibreOffice build shipped by Fedora, as the build distributed by libreoffice.org performs in your testcase impeccably on Fedora 23, like you say it does on Windows. And it is not only scrolling but e.g. text input in Writer as well that lags.
Comment 5 Ilja Sekler 2016-02-09 14:49:45 EST
It looks like this issue has to be attributed to the binary NVIDIA driver as I failed to reproduce the repaint / scrolling / text input woes on an ancient and extremely underpowered netbook with Intel graphics as well as on a computer with a GeForce GTX 650 Ti but with nouveau.

Nevertheless, as nouveau is currently not a viable option at least for computers with the Maxwell generation NVIDIA GPUs, it would be great to investigate why the LibreOffice build shipped by Fedora turns out to be virtually unusable with the binary driver while the build distributed by libreoffice.org is fine. If it is a driver bug, taking the burden of letting NVIDIA know would be highly appreciated.
Comment 6 Ilja Sekler 2016-02-17 19:12:07 EST
It turns out to be that installing the libreoffice-gtk3 package, which is not pulled in by the libreoffice meta package, solves the redraw / scrolling issue as of version 1: when using the binary NVIDIA driver. Unfortunately, it breaks font anti-aliasing within displayed documents forcing it to grayscale with apparently full hinting. The GUI meanwhile correctly inherits the font smoothing settings of the GNOME desktop, in my case subpixel AA + slight hinting + lcddefault filtering.

Without libreoffice-gtk3, the Fedora's build of LibreOffice looks pretty, but is unusable in combination with the binary NVIDIA driver.

I wonder if replacing --enable-gtk3 with --disable-gtk3 at


like it has been done for RHEL in


could result in a local build as usable as the libreoffice.org's one without dropping or touching any of the abundant Fedora patches.
Comment 7 David Tardon 2016-02-18 00:45:24 EST
(In reply to Ilja Sekler from comment #6)
> I wonder if replacing --enable-gtk3 with --disable-gtk3 at
> could result in a local build as usable as the libreoffice.org's one without
> dropping or touching any of the abundant Fedora patches.

It could not. That flag only enables/disables the gtk3 VCL plugin, which is packaged in libreoffice-gtk3.
Comment 8 Ilja Sekler 2016-02-18 18:03:56 EST
Thank you for the clarification. Anyway, an attempt to build a vanilla LibreOffice following the standard procedure https://wiki.documentfoundation.org/Development/BuildingOnLinux and using the libreoffice- tarball from the libreoffice- failed short of 6(!) hours of compiling in a unit test which should have been fixed according to https://bugs.documentfoundation.org/show_bug.cgi?id=76140 ("double equality assertion failed" from […]/workdir/CppunitTest/sc_opencl_test.test) :-(

I'm sorry, but experiments with building LibreOffice locally are out of scope for me on my current hardware, even if using system libs when building it the Fedora way would save an hour or two.
Comment 9 NSLW 2016-04-09 05:53:53 EDT
I'm experiencing issue described here too.
I use:
1) Fedora 23 x64
2) KDE
3) NVIDIA 340.96
4) LibreOffice

It didn't happen with LO Issue is gone after installing libreoffice-gtk3.
Comment 10 ernest.beinrohr 2016-04-15 03:03:42 EDT
Another confirm. after libreoffice-gtk3 LO is almost usable again. I use documents with images btw.

fc23, cinnamon, nvidia, lo
Comment 11 Gilboa Davara 2016-06-11 01:57:33 EDT
At least on my machine, the situation is so bad (even w/ libreoffce-gtk3) that I'm forced to use an old LibreOffice (5.0) running on an old Fedora VM (!).

Anyone has any idea what the source of this breakage? nVidia driver?

- Gilboa
Comment 12 Gilboa Davara 2016-06-11 02:07:02 EDT
Short followup:
Installed the LibreOffice stock RPMs (from libreoffice.org) and an I can confirm this issue is specific to the Fedora RPMs.
Stock libreoffice-calc is scroll/repaint is fast and there are no rendering artifacts.

- Gilboa
Comment 13 Ilja Sekler 2016-07-18 17:24:14 EDT
FYI: I've upgraded to F24 and the issue doesn't exist there.

rpm -q libreoffice-core

NVIDIA driver version: 361.45.11
Comment 14 George 2016-08-10 02:30:51 EDT
Libreoffice 5.2 from libreoffice rpms is painfully slow at re-drawing/loading spreadsheets in Scientific Linux 7  (RHEL7 equivalent).
KDE, nvida driver from elrepo.
Comment 15 jeremy9856 2016-08-10 05:05:09 EDT
I have this problem too. I use the GTK2 backend due to theme compatibility problem with the GTK2 backend.

 export SAL_USE_VCLPLUGIN=gtk	

Fedora 24 (Gnome)
Nvidia 367.35
Comment 16 jeremy9856 2016-08-10 06:58:41 EDT
Work much better with the GTK3 backend.
Comment 17 Caolan McNamara 2016-08-10 08:03:31 EDT
Its possible that this will be fixed by https://cgit.freedesktop.org/libreoffice/core/commit/?id=705d7597480b2307d7e4929ce9386d80ce2a0f16 which I'll include in the update.
Comment 18 jeremy9856 2016-08-12 05:28:33 EDT
Thanks for the update ! That fix the bug for me. LO is fast again with GTK2 backend.

Comment 19 Caolan McNamara 2016-08-12 09:10:50 EDT
That sounds very promising. I'll make a f23 update with a backport of that too then.
Comment 20 Fedora Update System 2016-08-13 12:13:18 EDT
libreoffice- has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-68e070b17d
Comment 21 Fedora Update System 2016-08-13 20:49:42 EDT
libreoffice- has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-68e070b17d
Comment 22 George 2016-08-16 23:31:21 EDT
This has been fixed for SL7 (RHEL7) x86_64 by the development version



Comment 23 fab 2016-09-01 09:18:55 EDT
*** Bug 1372334 has been marked as a duplicate of this bug. ***
Comment 24 Fedora Update System 2016-09-10 01:20:56 EDT
libreoffice- has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
Comment 25 Martijn Kruiten 2016-11-28 08:09:38 EST
I have exactly this problem on a MacBook Pro 2010 with dual graphics Intel/NVIDIA running a X-session on Fedora 25. It's fixed by installing the RPMs from LibreOffice and running that version. It's actually my girlfriend's laptop and she's got it with her, but I believe it says Gallium 0.4 on NVA5 on the info screen. What information can I provide to help fixing this?
Comment 26 Caolan McNamara 2016-11-29 06:26:33 EST
Martijn: you quite probably have a different bug given the very different version numbers in F25 and by using the rpms from upstream you may have simply done the equivalent of using the gtk2 backend instead of the gtk3 backend. If you have a problem in f25 please open a separate bug for that. Bugs like "libreoffice is slow" is such a generic title that it'll become just a fly trap bug for all sorts of problems otherwise

Note You need to log in before you can comment on or make changes to this bug.