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): libreoffice-core-5.0.4.2-3.fc23.x86_64 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).
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 5.0.4.2 build distributed by libreoffice.org is not affected.
It is something with 5.0.4.2 on Linux! Following test with 5.0.4.2 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...
Forgot to mention that it is MATE desktop...
(In reply to p1mail2015 from comment #2) > Following test with 5.0.4.2 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 5.0.4.2 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.
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.
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:5.0.5.2-1.fc23 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 http://pkgs.fedoraproject.org/cgit/rpms/libreoffice.git/tree/libreoffice.spec?h=f23#n1060 like it has been done for RHEL in http://pkgs.fedoraproject.org/cgit/rpms/libreoffice.git/commit/?id=492c0aeed5eeb0cc2494e6b64e0bd999ad13b3d3 could result in a local build as usable as the libreoffice.org's one without dropping or touching any of the abundant Fedora patches.
(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.
Thank you for the clarification. Anyway, an attempt to build a vanilla LibreOffice 5.0.5.2 following the standard procedure https://wiki.documentfoundation.org/Development/BuildingOnLinux and using the libreoffice-5.0.5.2.tar.xz tarball from the libreoffice-5.0.5.2-1.fc23.src.rpm 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.
I'm experiencing issue described here too. I use: 1) Fedora 23 x64 2) KDE 3) NVIDIA 340.96 4) LibreOffice 5.0.5.2-6 It didn't happen with LO 5.0.0.5. Issue is gone after installing libreoffice-gtk3.
Another confirm. after libreoffice-gtk3 LO is almost usable again. I use documents with images btw. fc23, cinnamon, nvidia, lo 5.0.5.2-6
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
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
FYI: I've upgraded to F24 and the issue doesn't exist there. rpm -q libreoffice-core libreoffice-core-5.1.5.1-1.fc24.x86_64 NVIDIA driver version: 361.45.11
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.
I have this problem too. I use the GTK2 backend due to theme compatibility problem with the GTK2 backend. /etc/profile.d/libreoffice-fresh.sh export SAL_USE_VCLPLUGIN=gtk Fedora 24 (Gnome) LO 5.1.5.2-1 Nvidia 367.35
Work much better with the GTK3 backend.
Its possible that this will be fixed by https://cgit.freedesktop.org/libreoffice/core/commit/?id=705d7597480b2307d7e4929ce9386d80ce2a0f16 which I'll include in the update.
Thanks for the update ! That fix the bug for me. LO is fast again with GTK2 backend. https://bodhi.fedoraproject.org/updates/FEDORA-2016-42080a7769
That sounds very promising. I'll make a f23 update with a backport of that too then.
libreoffice-5.0.6.2-10.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-68e070b17d
libreoffice-5.0.6.2-10.fc23 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
This has been fixed for SL7 (RHEL7) x86_64 by the development version LibreOffice_5.2.1.1_Linux_x86-64_rpm.tar.gz at http://dev-builds.libreoffice.org/pre-releases/rpm/x86_64/
*** Bug 1372334 has been marked as a duplicate of this bug. ***
libreoffice-5.0.6.2-10.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
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?
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