Created attachment 1127418 [details] Screenshot when only scrolling the document with top showing Xorg at 99,7% Description of problem: I'm scrolling document with 40 pages in libreoffice, and it scrolls very slowly and I can notice with top that the Xorg process is running at 80%-100% CPU, while the soffice.bin process is using at most 4% CPU. As soon as I stop scrolling, the CPU usage of Xorg drops to 0%-1%. This behavior is not image-dependent, because it happens with text-only pages and with tables too. I'm using a very fast machine with a very fast GPU, so this slowness is really unexpected. The workstation configuration: 6-core Intel(R) Xeon(R) CPU E5-2640 @ 2.50GHz 16GB RAM with 11GB free NVIDIA Corporation GK107GL [Quadro K2000] (rev a1), performs glxgears@33000fps -direct rendering: Yes -server glx vendor string: NVIDIA Corporation -server glx version string: 1.4 -OpenGL vendor string: NVIDIA Corporation -OpenGL renderer string: Quadro K2000/PCIe/SSE2 -OpenGL core profile version string: 4.4.0 NVIDIA 358.16 -OpenGL core profile shading language version string: 4.40 NVIDIA via Cg compiler -OpenGL version string: 4.5.0 NVIDIA 358.16 -OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 358.16 Version-Release number of selected component (if applicable): libreoffice-writer-5.0.5.2-1.fc23.x86_64 libreoffice-kde-5.0.5.2-1.fc23.x86_64 How reproducible: Always. I can even reproduce with a 6-page document with only text and tables. I tried disabling compositor but it does not help, also tried enabling triple buffer at nvidia section in xorg.conf, but also nothing changed. Steps to Reproduce: 1. Open a document in writer 2. Scroll up and down 3. See on konsole the process Xorg consume between 80 and 99% CPU Actual results: Hangs a lot, very slow rendering, very slow scrolling. Other applications work normally, like Firefox or Thunderbird. Expected results: Should scroll normally, in fact, should be lighting fast, since the hardware I'm using is a high-end machine. Additional info: Multi-headed configuration with 2 monitors @ 1600x1200 xorg-x11-server-Xorg-1.18.0-2.fc23.x86_64 kf5-kinit-5.18.0-1.fc23.x86_64
Tried the installation of libreoffice-gtk3 according to BUG #1303562 ( https://bugzilla.redhat.com/show_bug.cgi?id=1303562 ) but nothing changed, still high CPU usage by XOrg. Maybe because I'm using KDE?
This happens with LibreOffice 5.0.6.2 in Fedora 23 in i3 WM as well. It's so slow it's unusable as it rerenders itself for cca 3 second everytime the workspace is switched back and forth. Scrolling is also superslow. I should note that I also have nVidia proprietary driver installed so it seems like it's the culprint even though I've disabled OpenCL and HW accel in LibreOffice settings.
Can confirm the same, Fedora 23, i3, LibreOffice 5.0.5.2. At this point I dread receiving Excel files, feels like a 1980s era modem connection, but worse. If anyone has a workaround, please do share.
Can confirm for scrolling and also when writing a lot (i.e: let letter a pressed for a while, CPU usage goes UP, and letter is not render until stop pressing it whe the whole line appears) Fedora 24. LibreOffice Version: 5.1.5.2 Build ID: 5.1.5.2-6.fc24 Intel(R) Core(TM) i5-4200U CPU @ 1.60GHz
Created attachment 1202625 [details] Video showing the high cpu. Here you can see how the CPU ussage goes UP when I'm writing. And whe I stop, it goes down. You can see the process that are taking the cpu.
This makes writing any document almost impossible. Please check it, and tell us if we can provide any additional data.
Created attachment 1202771 [details] fine for me
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.