Description: When using KDE Wayland on a laptop with an AMD integrated GPU, I get some high CPU spikes and massive lag when i scroll through a document. Large documents (tens of thousands of words, zero images) are near-unusable, but this is noticeable even on an empty one-page document. On an X11 session, scrolling is perfectly smooth. Steps to Reproduce: 1. Start a KDE Wayland session 2. Open LibreOffice Writer 3. Scroll Actual Results: Choppy scrolling and high CPU usage Expected Results: Smooth scrolling, like in X11 Reproducible: Always User Profile Reset: No Additional Info: This is on LO 7.4.3.2, kf5 (cairo+wayland) Linux 6.0 (Fedora 37). I have smooth scrolling disabled and hardware acceleration enabled (toggling any of these settings makes no difference). I do use fractional scaling on Wayland, but then again it doesn't make a difference, the only factor that makes it not lag seems to be not using Wayland at all. Starting LO in Safe Mode does not make a difference either.
Could not reproduce with: Version: 7.4.3.2 / LibreOffice Community Build ID: 1048a8393ae2eeec98dff31b5c133c5f1d08b890 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+wayland) Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Integrated GPU: Intel Corporation UHD Graphics 620 (rev 07) Could you maybe share an example document where the lag is clearly visible, for others to test?
Upon further testing the problem does seem to be fractional scaling, since setting scaling to 1x and only then opening a new instance of LO has no issues. Since KDE renders at double the resolution to achieve fractional scaling, it may just be my computer not being able to render LO scrolling at 4K (AMD Ryzen 5 laptop). The Flatpak version runs better (still choppy), the non-Flatpak skips all the graphics tests so I may be missing something graphics related as well. I'll leave it up to you whether to close this one. Thanks!
[Automated Action] NeedInfo-To-Unconfirmed
I could actually reproduce some very sluggish scrolling. On Ubuntu 20.04 with GNOME + Wayland, all my displays at 200% scaling, starting LO with: And then changing all my displays' scaling back to 100% (with LO still open), I end up with extremely choppy scrolling with the mousewheel, and even more so by dragging the scrollbar: it struggles so much that it hangs, and I managed to make it crash(?) with the console message: The Wayland connection broke. Did the Wayland compositor die? (The LO window disappears, but I still had to kill the process in the console.) Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 92deea6301a02f5530f17263f58402344f82013c CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+wayland) Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Not reproducible with GTK3.
I can reproduce this bug, both with an AMD integrated GPU and with Intel UHD Graphics 620 and with scaling at 100%. On wayland scrolling lags and on X11 itś perfectly smooth. The problem has been there for months, at least since LO 7.5.0 (possibly its always been there). As someone else reported, hen trying "Run Graphics Tests" everything skips on both my AMD and Intel machines on wayland (I haven´t tried the flatpack version). So I don´t think it has to do with scaling or with AMD. Version: 7.5.5.2 (X86_64) / LibreOffice Community Build ID: 50(Build:2) CPU threads: 12; OS: Linux 6.2; UI render: default; VCL: kf5 (cairo+wayland) Locale: en-GB (en_GB.UTF-8); UI: en-GB Ubuntu package version: 4:7.5.5-0ubuntu0.23.04.1 Calc: threaded Operating System: Kubuntu 23.04 / KDE Neon (based on Ubuntu 22.04) KDE Plasma Version: 5.27.7 KDE Frameworks Version: 5.109.0 Qt Version: 5.15.8 / 5.15.10 Kernel Version: 6.2.0-27-generic (64-bit) Graphics Platform: Wayland Processors: AMD Ryzen 5 PRO 6650U with Radeon Graphics / Intel i5-8350U Memory: 30.7 GiB of RAM Graphics Processor: AMD Radeon Graphics / Intel UHD Graphics 620
Update: ======= using VCL: gtk3 brings back smooth scrolling on wayland. So the issue seem to be with the kf5 vcl plugin or actually with Qt. Can anyone reproduce / confirm??
Another update (and I promise after that I'll stop spamming this bug report): =============== While I do not use fractional scaling, I use two screens. If I unplug my external screen I get pretty smooth scrolling again on wayland with the kf5 vcl (it somewhat does not quite feel as smooth as in X11 or in Wayland with gtk3 vlc but it's definitely hardly noticeable and certainly not bothering).
As a sanity/insanity check, can folks try reproducing when running LO as root? I see far slower scrolling on the same OS (Fedora 38 now, but saw this with Ubuntu 20 too) - https://bugs.documentfoundation.org/show_bug.cgi?id=153985#c15
I can still reproduce in 7.6, in two ways, with or without two displays, and with or without scaling: (1) With a single display, reducing scaling while LO is open (as in comment 4, but only 1 display) (2) With two extended display, both at 100% scaling, _when the window spans the two screens_. Version: 7.6.4.1 (X86_64) / LibreOffice Community Build: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+wayland) Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Same with qt5 (cairo+wayland). Same back in 7.3.7.2. Michael, wondering if the two methods above give some interesting clues?
Created attachment 192315 [details] Sample document with many words
(In reply to Stéphane Guillou (stragu) from comment #9) > I can still reproduce in 7.6, in two ways, with or without two displays, and > with or without scaling: > > (1) With a single display, reducing scaling while LO is open (as in comment > 4, but only 1 display) > > (2) With two extended display, both at 100% scaling, _when the window spans > the two screens_. So far, I cannot reproduce on Debian testing (qtbase packages at version 5.15.10+dfsg-6). Both of the scenarios work fine for me when using attachment 192315 [details] as document when testing. > Same with qt5 (cairo+wayland). > > Same back in 7.3.7.2. > > Michael, wondering if the two methods above give some interesting clues? Hard to say, since I cannot reproduce locally. A flamegraph (see [1]) might give clues of where CPU time is spent. Does this also happen with the qt6 VCL plugin or only with qt5/kf5? (qt6 plugin is not yet part of TDF-provided packages yet, so would e.g. either need an `--enable-qt6` local build or package libreoffice-qt6 from a Debian-based distro). [1] https://wiki.documentfoundation.org/Development/How_to_debug/en#Performance_debugging_(perf) Version: 24.2.0.2 (X86_64) / LibreOffice Community Build ID: 420(Build:2) CPU threads: 12; OS: Linux 6.5; UI render: default; VCL: kf5 (cairo+wayland) Locale: en-GB (en_GB.UTF-8); UI: en-GB Debian package version: 4:24.2.0~rc2-2 Calc: threaded
Created attachment 192316 [details] Hotspot flamegraph of scrolling using scrollbar w/ qt6 on Wayland
(In reply to Michael Weghorn from comment #11) > So far, I cannot reproduce on Debian testing (qtbase packages at version > 5.15.10+dfsg-6). Both of the scenarios work fine for me when using > attachment 192315 [details] as document when testing. OK, I can somewhat reproduce something now: 1) open attachment 192315 [details] with kf5/qt5/qt6 on Wayland 2) move through the document by dragging the handle in the vertical scrollbar There's a delay to update the view and it's sometimes stuck for maybe 1-2 seconds before the view updates. It's smooth when forcing the use of the x11 Qt backend (running via XWayland) by setting env variable QT_QPA_PLATFORM=xcb. Answering my own questions: > A flamegraph (see [1]) might give clues of where CPU time is spent. attachment 192316 [details] is a flamegraph with qt6, using local LO and qtbase debug builds. It shows that most time seems to be spent in rendering the document, triggered by the scrolling. Maybe something is different in how Qt handles the mouse events on Wayland as compared to X11 (s. e.g. the QtWidget::mouseMoveEvent in the flamegraph), like maybe events are triggered more often now, so re-rendering the doc happens more often? (Just a wild guess.) This would need further analysis to be able to say anything specific and I don't see any obviously wrong in the flamegraph by itself otherwise, I'd expect the call stack to generally be the same with X11. > Does this also happen with the qt6 VCL plugin or only with qt5/kf5? Same with qt6.
(In reply to Michael Weghorn from comment #13) > OK, I can somewhat reproduce something now: > > 1) open attachment 192315 [details] with kf5/qt5/qt6 on Wayland > 2) move through the document by dragging the handle in the vertical scrollbar Note: This is with a dual-screen setup, both screens using 100% scaling and LO just being maximized on one of the screens, so nothing particularly special in the display settings.
(In reply to Michael Weghorn from comment #13) > Maybe something is different in how Qt handles the mouse events on Wayland > as compared to X11 (s. e.g. the QtWidget::mouseMoveEvent in the flamegraph), > like maybe events are triggered more often now, so re-rendering the doc > happens more often? (Just a wild guess.) Note also the `QWindowSystemInterface::sendWindowSystemEvents` further down in the call stack, which is likely triggered by some event from the window system (Wayland/X11), which is where a Wayland vs. X11 difference might come from from further down the stack, which would then potentially be something outside of the direct control of LO and even Qt.
*** Bug 160235 has been marked as a duplicate of this bug. ***
*** Bug 153111 has been marked as a duplicate of this bug. ***
*** Bug 159789 has been marked as a duplicate of this bug. ***
I have some video evidence of this in action. It seems to get much worse at higher resolutions. VIDEO LINK: https://www.youtube.com/watch?v=EXyMSzOVsds Hardware: 13700k 7900xt 32gb DDR5 2tb SSD NVME Software/OS: Fedora 40 Linux 6.8x LibreOffice 24.2.3.2 hTOP Gnome 46 Gnome-Terminal GPU drivers, VCL version, GTK version, etc, etc - whatever is on Fedora 40 as of this video. Confirmed My Testing With: 2700x RX 580 8gb 16gb DDR4 1tb SSD SATA Linux 5.x LibreOffice 7.6+ Note: This seems to happen regardless of using gtk, qt, whether it's on Xorg, Wayland, a Debian distro, an Arch distro, etc. I've been able to confirm on different hardware and since version 7.6+ of LibreOffice. I tested it on 15k words to 50k words, 30 pages to 72 pages - it has high CPU usage either way.
Just some wild "what if?..." guessing based on what M. Knepper's video in comment #19 about the high CPU usage in htop while scrolling a wall of text... * Let's say you grab a 4K screen, but do not set the display scaling to 2x HiDPI, just use it at its "native panel resolution", and size the libreoffice window at various sizes (ex: a quarter of the screen, half of the screen, full size of the screen, etc., do you still see this happening, and do you see differences in the percentage of CPU used in each case? * Could Cairo be the bottleneck? I see we're all running the Cairo version of LibreOffice, not Skia: as far as I know, Cairo is all CPU rendering, whereas Skia renders everything (I think?) on the GPU and should be an order of magnitude faster as a result. Maybe you could try running the Skia version (using the trick in https://github.com/flathub/org.libreoffice.LibreOffice/issues/213#issuecomment-1450176774 for the flathub flatpak version) and see if the problem vanishes with it?
(In reply to Jeff Fortin Tam from comment #20) > Just some wild "what if?..." guessing based on what M. Knepper's video in > comment #19 about the high CPU usage in htop while scrolling a wall of > text... > > * Let's say you grab a 4K screen, but do not set the display scaling to 2x > HiDPI, just use it at its "native panel resolution", and size the > libreoffice window at various sizes (ex: a quarter of the screen, half of > the screen, full size of the screen, etc., do you still see this happening, > and do you see differences in the percentage of CPU used in each case? > > * Could Cairo be the bottleneck? I see we're all running the Cairo version > of LibreOffice, not Skia: as far as I know, Cairo is all CPU rendering, > whereas Skia renders everything (I think?) on the GPU and should be an order > of magnitude faster as a result. Maybe you could try running the Skia > version (using the trick in > https://github.com/flathub/org.libreoffice.LibreOffice/issues/ > 213#issuecomment-1450176774 for the flathub flatpak version) and see if the > problem vanishes with it? The Fedora video was recorded with a scaling of 100%, forgot to mention that. So the video I recorded in question is 1x scaling. My guess is it will be much, much worse if I set it to 200%. Additional Note: Walls of text do not seem to be an issue in other word processors. For instance, I write novels (80k words plus, 100s of pages), and it's fine in MS Word. I can open the same document (either .docx or .odt format) and the same problem occurs - LibreOffice will use 80%~ or so of the CPU. I'll try forcing Skia if Fedora/24.x will let me. But yeah, the video I recorded was at 100% scaling or 1x, not 200% or any other fraction (though I'm able to reproduce this problem with fractional scaling on Linux Mint MATE and Cinnamon).
I suffer from the very same issue. My system: Operating System: openSUSE Tumbleweed 20240607 KDE Plasma Version: 6.1.80 KDE Frameworks Version: 6.4.0 Qt Version: 6.7.1 Kernel Version: 6.9.3-1-default (64-bit) Graphics Platform: Wayland Processors: 20 × 13th Gen Intel® Core™ i7-13700H Memory: 62.5 GiB of RAM Graphics Processor: Mesa Intel® Graphics Manufacturer: TUXEDO Product Name: TUXEDO InfinityBook Pro Gen8 (MK1) I use fractional scaling and it appears no matter whether using qt5 or qt6 VCL, GTK/GNOME VCL appears to be fine here.
I have this issue in Plasma 6, Wayland, NixOS Unstable 24.11 (all up to date), Intel UHD graphics. LO Version Info: Version: 24.2.3.2 (X86_64) / LibreOffice Community Build ID: 420(Build:2) CPU threads: 8; OS: Linux 6.8; UI render: default; VCL: kf5 (cairo+wayland) Calc: threaded It is not a fractional scaling issue, it is a window size issue – scaling may make it worse but it happens regardless. A larger window means more lag, but at least for me some lag is still present even on a small window, single monitor, it just doesn't make scrolling unusable like it does on a larger window size. The size of the document also makes no difference to me; I get the same lag on an empty document as a 30 page one filled with text. Lag does not affect moving between pages by moving the cursor, including pg up/dn, only scrolling using scroll wheel on mouse or two finger scroll on trackpad, or scrolling by dragging scroll bar. I can't really tell for sure if middle click scrolling is the same, it seems like it is just scrolling very slow even when it should be scrolling at speed. I have tried the GTK version of LibreOffice and had the same issue (in Plasma 6). I wonder if enabling OpenCL would fix this, but I have never been able to get LO to use OpenCL despite other apps (e.g. DaVinci Resolve) being able to use it just fine and clinfo saying I have two OpenCL platforms installed. I have installed every driver related to OpenGL or OpenCL I could find. This page https://ask.libreoffice.org/t/unable-to-activate-opencl/45714/6 suggests the driver(s) may not be whitelisted properly? I didn't understand most of this. Final note: Fractional scaling is not good regardless of this particular issue. Based purely on how the font rendering looks, fractionally scaled windows *seem* to be downscaled from a higher integer scaled resolution. This is a separate issue that should be fixed, but it to me explains why fractional scaling makes this worse in the same way increasing the window size does, because using fractional scaling is analogous to increasing the window size (then downscaling).
*** Bug 162585 has been marked as a duplicate of this bug. ***
I can reproduce every part of this bug on my system as well. It's very annoying, hopefully it gets fixed soon. My system: DE: Plasma 6.1.4 OS: Fedora 40 x86_64 Kernel: Linux 6.9.12-200.fc40.x86_64 (I'm not on 6.10 due to a separate issue) WM: KWin (Wayland) CPU: Intel Core Ultra 7 155H (22) @ 4.80 GHz GPU: Intel Graphics @ 2.25 GHz [Integrated] LibreOffice: 24.2.5.2, kf6 I notice that when scrolling, one of my threads has very high usage while all others have very low usage. I experience considerable lag when scrolling through any Writer document. As in Comment 13, Running LO with QT_QPA_PLATFORM=xcb fixes the lag issues, although it messes with the application's display scaling. As in Comment 23, it appears to be a window size issue to me. I usually use 150% display scaling. Setting my display scaling to 100% makes the lag slightly better, but it is still very present. I have been able to get OpenCL working on my system, to test the theory of Comment 23. Sadly, this does not seem to affect the issue at all for me, as do any of the other graphical settings in LibreOffice itself. Smooth scrolling is disabled, as it makes the problem worse when enabled. I hope some of this information helps and look forward to any other contributions I can make to resolve this issue.
I can also confirm this bug is still present here: LO: 24.8.0.3 (x86_64) / Libreoffice Community VCL: kf6 (cairo + wayland) Operating System: openSUSE Tumbleweed 20240823 KDE Plasma Version: 6.1.80 KDE Frameworks Version: 6.6.0 Qt Version: 6.7.2 Kernel Version: 6.10.5-1-default (64-bit) Graphics Platform: Wayland Processors: 20 × 13th Gen Intel® Core™ i7-13700H Memory: 62.5 GiB of RAM Graphics Processor: Mesa Intel® Graphics Manufacturer: TUXEDO Product Name: TUXEDO InfinityBook Pro Gen8 (MK1) It is a longstanding issue here and I would really like to see it fixed.
*** Bug 162356 has been marked as a duplicate of this bug. ***
I can confirm this on Fedora Workstation 40 all packages updated. DE: GNOME 46.4 Both the Fedora RPM and the Flatpak version are affected. Heres the flatpak details: Version: 24.8.0.3 (X86_64) / LibreOffice Community Build ID: 0bdf1299c94fe897b119f97f3c613e9dca6be583 CPU threads: 8; OS: Linux 6.10; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Flatpak Calc: threaded Dont have the version info of the RPM version as I deleted that and am defaulting to the flatpak. Regardless of fractional scaling or not, in Wayland, this happens. Previously I had a KDE install and there it worked fine IF xwayland was forced via QT_QPA_PLATFORM=xcb with the kf6 backend. In GNOME however, even with the GDK_BACKEND=x11 using the gtk3 backend, scrolling is still laggy. The other backend i tried was x11 using SAL_USE_VCLPLUGIN=gen and that worked although LO does not recognize the system theme and has an outdated windows 98 look. However, here the scrolling was much better.
*** Bug 162817 has been marked as a duplicate of this bug. ***
Just an observation... today I was testing LibreOffice under Cosmic using the kf6 VCL and Wayland to see if LO was working fine (I'm on Fedora 40). One thing I noticed is that scrolling documents is a lot faster on Cosmic. Some documents that struggle under Plasma 6 Wayland scroll quite smoothly under Cosmic. This suggests that maybe this is a Kwin issue. Also, Cosmic does not theme LibreOffice quite well at the moment... When using dark mode in Cosmic, launching LO with kf6 will result in light colors. Anyways, this is a topic for a ticket at the Cosmic repo.
LibreOffice works fine under Wayland if it runs on GNOME. It lags when scrolling on KDE plasma 6.1 under Wayland.
Or at least it seems to be that way on Fedora 40,
Same here on fedora 40 kde (plasma 6.1, wayland), but it was also the case with KDE Neon ages ago as reported above. However today something interesting happened. I realised that by tiling a doc on only half the screen, the scrolling got smoother, and got slower again when putting the doc back into full screen. Just saying in case that helps with finding out where the issue might come from.
Seems like setting VCL_DOUBLEBUFFERING_FORCE_ENABLE=1 mostly fixes this
tested with >VCL_DOUBLEBUFFERING_FORCE_ENABLE=1 libreoffice I do not see any difference here.
(In reply to robby.engelmann from comment #35) > tested with > >VCL_DOUBLEBUFFERING_FORCE_ENABLE=1 libreoffice > I do not see any difference here. Me too, no luck.
Reported bug at https://bugs.kde.org/show_bug.cgi?id=494299 seems to be a KDE plasma issue.
Hi ! I found a workaround on the ArchLinux wiki ; I paste the relevant entry below : "KDE Plasma/GNOME + Wayland with or without fractional scaling results in terrible lag when scrolling Users of KDE Plasma 6 and 5 and some users testing with GNOME have reported issues of terrible lag while scrolling through documents as reported in [6]. Running LibreOffice through X11 can solve the issue (There are reports that the issue is not resolved in GNOME when using the GTK3 backend). This can be done individually by the setting the environment variable QT_QPA_PLATFORM=xcb libreoffice while in KDE Plasma (QT) or GDK_BACKEND=x11 libreoffice while in GNOME (GTK). Each .desktop file can be edited to permanently apply the change until a fix is found. Users can also switch back to X11 to mediate the issue. "
With the latest update to the COSMIC DE, it seems LibreOffice now runs on that DE as poorly as it does on KDE plasma 6.2. Now the only de I know that runs LibreOffice well is GNOME 46. It doesn't matter if you run in the terminal "SAL_USE_VCLPLUGIN=gtk3 libreoffice --writer" or "SAL_USE_VCLPLUGIN=kf6 libreoffice --writer" to run LibreOffice
(In reply to Mahendra Tallur from comment #38) > QT_QPA_PLATFORM=xcb libreoffice while in KDE Plasma (QT) or GDK_BACKEND=x11 > libreoffice while in GNOME (GTK). Each .desktop file can be edited to > permanently apply the change until a fix is found. I am now using that, thank you for relaying that. I am also finding typing more responsive (lower delay) through XWayland, although I didn't realise it was slow in Wayland until I switched.
(In reply to miafr30m from comment #40) > (In reply to Mahendra Tallur from comment #38) > > QT_QPA_PLATFORM=xcb libreoffice while in KDE Plasma (QT) or GDK_BACKEND=x11 > > libreoffice while in GNOME (GTK). Each .desktop file can be edited to > > permanently apply the change until a fix is found. > > I am now using that, thank you for relaying that. I am also finding typing > more responsive (lower delay) through XWayland, although I didn't realise it > was slow in Wayland until I switched. I spoke too soon. Scrolling is MUCH better in XWayland but still pretty laggy, and ignoring fast scroll inputs.
6 duplicates now, let's increase the importance.
Doing some testing on ubuntu 24.04 and 24.10 under plasma 5.27 and plasma 6.1 respectively the issue is not present on wayland! scrolling may not be very smooth but it is consistently usable, on documents without images tested up to 97 pages. Maybe it seems to only affect RPM based distros like Fedora and openSUSE.
(In reply to ppaanncchhoo507 from comment #43) > Doing some testing on ubuntu 24.04 and 24.10 under plasma 5.27 and plasma > 6.1 respectively the issue is not present on wayland! scrolling may not be > very smooth but it is consistently usable, on documents without images > tested up to 97 pages. Maybe it seems to only affect RPM based distros like > Fedora and openSUSE. When testing under ubuntu 24.04 the VCL was gtk3 and on ubuntu 24.10 the VCL was x11. Although here: https://bugs.kde.org/show_bug.cgi?id=494299 the VCL doesn't seem to matter. Given that it doesn't happen on ubuntu it's maybe distro specific
(In reply to ppaanncchhoo507 from comment #44) > (In reply to ppaanncchhoo507 from comment #43) > > Doing some testing on ubuntu 24.04 and 24.10 under plasma 5.27 and plasma > > 6.1 respectively the issue is not present on wayland! scrolling may not be > > very smooth but it is consistently usable, on documents without images > > tested up to 97 pages. Maybe it seems to only affect RPM based distros like > > Fedora and openSUSE. > > When testing under ubuntu 24.04 the VCL was gtk3 and on ubuntu 24.10 the VCL > was x11. Although here: https://bugs.kde.org/show_bug.cgi?id=494299 the VCL > doesn't seem to matter. Given that it doesn't happen on ubuntu it's maybe > distro specific i tested it with the latest packages from ubuntu. testing it with the latest packages from the libreoffice website the problem is present again. maybe the patches applied by ubuntu could be upstreamed?
(In reply to ppaanncchhoo507 from comment #44) > (In reply to ppaanncchhoo507 from comment #43) > > Doing some testing on ubuntu 24.04 and 24.10 under plasma 5.27 and plasma > > 6.1 respectively the issue is not present on wayland! scrolling may not be > > very smooth but it is consistently usable, on documents without images > > tested up to 97 pages. Maybe it seems to only affect RPM based distros like > > Fedora and openSUSE. > > When testing under ubuntu 24.04 the VCL was gtk3 and on ubuntu 24.10 the VCL > was x11. Although here: https://bugs.kde.org/show_bug.cgi?id=494299 the VCL > doesn't seem to matter. Given that it doesn't happen on ubuntu it's maybe > distro specific It doesn't seem to matter on Fedora 40, sorry i spoke too soon. first i have never installed kubuntu i first installed ubuntu and then the latest kde plasma on it from the ubuntu repos. anyways in ubuntu 24.04 the VCL does matter when using the latest packages from libreoffice. when testing packages from libreoffice i have always used the latest stable packages. when i use them in ubuntu 24.04 if i run libreoffice writer by running "SAL_USE_VCLPLUGIN=gtk3 ./opt/libreoffice24.8/program/soffice --writer" in the terminal the issue is not present and when i run "SAL_USE_VCLPLUGIN=kf5 ./opt/libreoffice24.8/program/soffice --writer" in the terminal the issue is present(In reply to ppaanncchhoo507 from comment #39) > With the latest update to the COSMIC DE, it seems LibreOffice now runs on > that DE as poorly as it does on KDE plasma 6.2. Now the only de I know that > runs LibreOffice well is GNOME 46. It doesn't matter if you run in the > terminal "SAL_USE_VCLPLUGIN=gtk3 libreoffice --writer" or > "SAL_USE_VCLPLUGIN=kf6 libreoffice --writer" to run LibreOffice this was run on Fedora 40.
*** Bug 163804 has been marked as a duplicate of this bug. ***
No activity here for a while. Now, I switched to the gtk3 VCL in order to be able to work. Change also to the current version.
(In reply to robby.engelmann from comment #48) > No activity here for a while. Now, I switched to the gtk3 VCL in order to be > able to work. > Change also to the current version. The earliest reportedly affected version was 7.3.7, so changing back.
*** Bug 165007 has been marked as a duplicate of this bug. ***
This bug makes LibreOffice **unusable** on a Wayland session. I'm on a high-end system with a Ryzen 5800X and an RTX 4070Ti Super, on the latest driver, and trying to scroll through a 20-something page document is unusable, and I'm not being hyperbolic, the program just cannot be used like this. I won't pretend to know why this issue is taking so long to fix, but I do have a question. Why not disable Wayland support by default if it's a known fact that it's broken? Then re-enable it once it's not broken? I'm currently resorting to launching LibreOffice from the terminal every time so I can pass the QT_QPA_PLATFORM=xcb envar ONLY to LibreOffice, but I don't think that's a reasonable solution. LibreOffice should default to X11 until the Wayland backend isn't broken.
(In reply to danileon95 from comment #51) > This bug makes LibreOffice **unusable** on a Wayland session. I'm on a > high-end system with a Ryzen 5800X and an RTX 4070Ti Super, on the latest > driver, and trying to scroll through a 20-something page document is > unusable, and I'm not being hyperbolic, the program just cannot be used like > this. > > I won't pretend to know why this issue is taking so long to fix, but I do > have a question. Why not disable Wayland support by default if it's a known > fact that it's broken? Then re-enable it once it's not broken? The experience seems to differ, depending on unknown factors. For example, in my setup (s. below for system details), there is a clearly noticeable (and annoying) lag on Wayland as compared to X11, but LO is still usable. Forcing LO to run on XWayland would be quite a "radical" step, and not what other users may be expecting. (I suppose that while Plasma Wayland has matured a lot over the last years, choosing to run Plasma X11 is still what some do whose primary goal is to avoid odd Wayland-specific issues. Others explicitly want Wayland and might not be happy about it silently "not being used" by some apps.) One aspect is also that disabling Qt's wayland QPA plugin by default would also mean that LO no longer gets used/tested with it - meaning that other potential issues are presumably not reported and fixed either. So in my opinion, forcing to run on X11 would require very strong reasons. (As I said, the experience I get in my setup isn't that bad, maybe would be useful to know more exactly what is causing the difference). I think one could also argue that the qt6/kf6 VCL plugin shouldn't be used by default at all, but the gtk3 one instead (which can be forced by using SAL_USE_VCLPLUGIN=gtk3), because it's the most mature one on Linux. Of course, any help to further analyze and fix the issue are more than welcome. After all, LO is an open source project that welcomes contributions: https://www.libreoffice.org/community/get-involved/ > I'm currently resorting to launching LibreOffice from the terminal every > time so I can pass the QT_QPA_PLATFORM=xcb envar ONLY to LibreOffice, but I > don't think that's a reasonable solution. LibreOffice should default to X11 > until the Wayland backend isn't broken. If you don't want to manually set the environment variable every time, one approach could be to modify the LibreOffice shell wrapper and set the environment variable there. Or, as mentioned above, set SAL_USE_VCLPLUGIN=gtk3 in your ~/.bashrc or similar. Operating System: Debian GNU/Linux 12 KDE Plasma Version: 6.3.0 KDE Frameworks Version: 6.10.0 Qt Version: 6.7.2 Kernel Version: 6.12.12-amd64 (64-bit) Graphics Platform: Wayland Processors: 32 × 13th Gen Intel® Core™ i9-13900HX Memory: 62.5 GiB of RAM Graphics Processor 1: Intel® Graphics Graphics Processor 2: NVIDIA GeForce RTX 4060 Laptop GPU Manufacturer: TUXEDO Product Name: TUXEDO Gemini Gen2 Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 8710a20fabcb8892d8f1f2ae917101028db61e39 CPU threads: 32; OS: Linux 6.12; UI render: default; VCL: qt6 (cairo+wayland) Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded
The problem with the env var approach is that I don't want other programs to be affected, only LibreOffice, since it's the one with the bug. I do want programs to use native Wayland, when it isn't broken. In that case, would it be reasonable to request that LibreOffice listens to an env var to force X11 that is unique to LibreOffice and not shared with Qt or gtk apps?
For your approach (assuming you are running Plasma) you'll want to use the Menu Editor to add the environment variable to LibreOffice's desktop launchers. This way you get the automatic usage of the environment variable without affecting other apps.
(In reply to pasta-grandpa-lard from comment #54) > For your approach (assuming you are running Plasma) you'll want to use the > Menu Editor to add the environment variable to LibreOffice's desktop > launchers. This way you get the automatic usage of the environment variable > without affecting other apps. I have tried but for some strange reason it does not work
Yeah, it doesn't work for me either, on Plasma 6.3.1 (EndeavourOS). The only thing that works for me is launching it via the terminal with the env var set manually. I don't know why.
(In reply to danileon95 from comment #53) > The problem with the env var approach is that I don't want other programs to > be affected, only LibreOffice, since it's the one with the bug. I do want > programs to use native Wayland, when it isn't broken. You can set the env variable in the LO shell wrapper, e.g. /usr/bin/libreoffice on Debian is a bash script that runs the soffice.bin executable, so any env vars you set in the shell script will apply only to LibreOffice.
Created attachment 199366 [details] env variable set on LibreOffice calc This seems to do the trick for me (applying the env var workaround) under Plasma 6
(In reply to Michael Weghorn from comment #57) > (In reply to danileon95 from comment #53) > > The problem with the env var approach is that I don't want other programs to > > be affected, only LibreOffice, since it's the one with the bug. I do want > > programs to use native Wayland, when it isn't broken. > > You can set the env variable in the LO shell wrapper, e.g. > /usr/bin/libreoffice on Debian is a bash script that runs the soffice.bin > executable, so any env vars you set in the shell script will apply only to > LibreOffice. Yes, but when LO is updated, the file is overwritten. It would be more useful to have an environment variable like LO_USE_XCB or SAL_USE_XCB or if you want to restrict the field to QT then LO_QT_USE_XCB
(In reply to Guido Iodice from comment #59) > Yes, but when LO is updated, the file is overwritten. It would be more > useful to have an environment variable like LO_USE_XCB or SAL_USE_XCB or if > you want to restrict the field to QT then LO_QT_USE_XCB True. I'm somewhat hesitant to make the the shell wrapper more complex, however. For now, I'd suggest either using SAL_USE_VCLPLUGIN=gtk3 (which is LO-specific), or editing the desktop file (to set the environment variable or to set a path that points to a wrapper that has the environment variable set, if directly setting the env variable doesn't work for whatever reason). But of course, feel free to create a separate feature request if you still think that this should be implemented.
If you use Arch, you can make use of the /etc/profile.d/libreoffice-fresh.sh script which will not get overwritten: https://wiki.archlinux.org/title/LibreOffice#Theme
(In reply to Michael Weghorn from comment #60) > (In reply to Guido Iodice from comment #59) > > Yes, but when LO is updated, the file is overwritten. It would be more > > useful to have an environment variable like LO_USE_XCB or SAL_USE_XCB or if > > you want to restrict the field to QT then LO_QT_USE_XCB > > True. I'm somewhat hesitant to make the the shell wrapper more complex, > however. > > For now, I'd suggest either using SAL_USE_VCLPLUGIN=gtk3 (which is > LO-specific), or editing the desktop file (to set the environment variable > or to set a path that points to a wrapper that has the environment variable > set, if directly setting the env variable doesn't work for whatever reason). > > But of course, feel free to create a separate feature request if you still > think that this should be implemented. I've also been experiencing this issue. My solution since November has been to add additional .desktop files to ~/.local/share/applications which start the app using QT_QPA_PLATFORM=xcb. This works for me, except of course, the X11 version looks odd with fractional display scaling (1.5x). Setting SAL_USE_VCLPLUGIN=gtk3 doesn't have issues with scaling, but scrolling is still inefficient and stuttery. It is much better than native, though, but causes the same spike in a single CPU core before stuttering when scrolling through long documents. The xcb version, however, barely uses any CPU no matter how fast or far I scroll in said long document. Since such smooth performance is available via XWayland while still running under a Wayland session, it makes me wonder whether the root problem is within Wayland itself or within LibreOffice's implementation thereof. Operating System: Fedora Linux 41 KDE Plasma Version: 6.3.1 KDE Frameworks Version: 6.11.0 Qt Version: 6.8.2 Kernel Version: 6.12.15-200.fc41.x86_64 (64-bit) Graphics Platform: Wayland Processors: 22 × Intel® Core™ Ultra 7 155H Memory: 46.7 GiB of RAM Graphics Processor: Mesa Intel® Arc Manufacturer: Notebook Product Name: V54x_6x_TU System Version: V540TU
(In reply to oirnoir from comment #62) > (In reply to Michael Weghorn from comment #60) > > (In reply to Guido Iodice from comment #59) > > > Yes, but when LO is updated, the file is overwritten. It would be more > > > useful to have an environment variable like LO_USE_XCB or SAL_USE_XCB or if > > > you want to restrict the field to QT then LO_QT_USE_XCB > > > > True. I'm somewhat hesitant to make the the shell wrapper more complex, > > however. > > > > For now, I'd suggest either using SAL_USE_VCLPLUGIN=gtk3 (which is > > LO-specific), or editing the desktop file (to set the environment variable > > or to set a path that points to a wrapper that has the environment variable > > set, if directly setting the env variable doesn't work for whatever reason). > > > > But of course, feel free to create a separate feature request if you still > > think that this should be implemented. > > I've also been experiencing this issue. > > My solution since November has been to add additional .desktop files to > ~/.local/share/applications which start the app using QT_QPA_PLATFORM=xcb. > This works for me, except of course, the X11 version looks odd with > fractional display scaling (1.5x). Setting SAL_USE_VCLPLUGIN=gtk3 doesn't > have issues with scaling, but scrolling is still inefficient and stuttery. > It is much better than native, though, but causes the same spike in a single > CPU core before stuttering when scrolling through long documents. The xcb > version, however, barely uses any CPU no matter how fast or far I scroll in > said long document. > > Since such smooth performance is available via XWayland while still running > under a Wayland session, it makes me wonder whether the root problem is > within Wayland itself or within LibreOffice's implementation thereof. > > Operating System: Fedora Linux 41 > KDE Plasma Version: 6.3.1 > KDE Frameworks Version: 6.11.0 > Qt Version: 6.8.2 > Kernel Version: 6.12.15-200.fc41.x86_64 (64-bit) > Graphics Platform: Wayland > Processors: 22 × Intel® Core™ Ultra 7 155H > Memory: 46.7 GiB of RAM > Graphics Processor: Mesa Intel® Arc > Manufacturer: Notebook > Product Name: V54x_6x_TU > System Version: V540TU OMG QT_QPA_PLATFORM=xcb is such a saver. Scrolling is back to perfectly smooth no matter my screen configurations. In my case editing adding the ENV variable through editing the various LO lunchers via KDE Kickoff menu edit worked brilliantly. The only drawback is that when opening a document it now creates an additional icon in the Icon-Only tasks manager on top of the pinned application icon.
*** Bug 165440 has been marked as a duplicate of this bug. ***
Here, adding QT_QPA_PLATFORM=xcb also solves the lags and CPU spikes. I am happy being back to a pleasant LO experience. Having this under native wayland is surely the future...
(In reply to robby.engelmann from comment #65) > Here, adding QT_QPA_PLATFORM=xcb also solves the lags and CPU spikes. I am > happy being back to a pleasant LO experience. Having this under native > wayland is surely the future... I sincerely hope that, someday, we will have equally smooth performance under native Wayland in LibreOffice, and that we won't have to force it to run through XWayland for it to have meaningfully smooth performance.
I can confirm the same issue happening in Hyprland when running Libreoffice using the QT6 VCL plugin Selecting, rotating and moving textboxs, images and gifs is laggy under wayland but when forced to use xbc backend by env QT_QPA_PLATFORM=xcb SAL_USE_VCLPLUGIN=qt6 libreoffice, the issues disappear, and ofcourse new xwayland issues appear This problem happens only in QT and not GTK Is their any update on fixing this issue?
On my machine SAL_USE_VCLPLUGIN=gtk3 doesn't have much of an effect. I can get very smooth scrolling with all three: VCL_DOUBLEBUFFERING_FORCE_ENABLE=1 QT_QPA_PLATFORM=xcb SAL_USE_VCLPLUGIN=kf6. Other fora (https://forum.qubes-os.org/t/libreoffice-is-very-slow-unlike-other-programs/26453/3) seem to recommend enabling Skia, so is there any reason not to always enable Skia, and use Cairo only as fallback ? I'm running the Fedora RPM LO, so I don't have the config option to enable Skia.
(In reply to Stelian Ionescu from comment #68) > On my machine SAL_USE_VCLPLUGIN=gtk3 doesn't have much of an effect. I can > get very smooth scrolling with all three: VCL_DOUBLEBUFFERING_FORCE_ENABLE=1 > QT_QPA_PLATFORM=xcb SAL_USE_VCLPLUGIN=kf6. > > Other fora > (https://forum.qubes-os.org/t/libreoffice-is-very-slow-unlike-other-programs/ > 26453/3) seem to recommend enabling Skia, so is there any reason not to > always enable Skia, and use Cairo only as fallback ? I'm running the Fedora > RPM LO, so I don't have the config option to enable Skia. Skia does not work yet with normal Linux UIs, only the fallback x11 or "gen" UI, which should not be used other than for development and testing.
*** Bug 165766 has been marked as a duplicate of this bug. ***
*** Bug 166163 has been marked as a duplicate of this bug. ***
Too many duplicates and no solution. What if we migrate to Qt? It is a cross-platform industry standard. Migration in the future will free up a lot of resources that are currently spent on supporting the useless VCL.
(In reply to tuefue from comment #72) > Too many duplicates and no solution. > > What if we migrate to Qt? It is a cross-platform industry standard. > Migration in the future will free up a lot of resources that are currently > spent on supporting the useless VCL. For a likely Qt upstream bug, you are suggesting to solve it by migrating to Qt, interesting. You may find it enlightening to know that Michael Weghorn has fixed several bugs in Qt itself, but may not have the time budget to constantly be maintaining this "industry standard" quality.
(In reply to Michael Weghorn from comment #52) > (In reply to danileon95 from comment #51) > > This bug makes LibreOffice **unusable** on a Wayland session. I'm on a > > high-end system with a Ryzen 5800X and an RTX 4070Ti Super, on the latest > > driver, and trying to scroll through a 20-something page document is > > unusable, and I'm not being hyperbolic, the program just cannot be used like > > this. > > > > I won't pretend to know why this issue is taking so long to fix, but I do > > have a question. Why not disable Wayland support by default if it's a known > > fact that it's broken? Then re-enable it once it's not broken? > > The experience seems to differ, depending on unknown factors. For example, > in my setup (s. below for system details), there is a clearly noticeable > (and annoying) lag on Wayland as compared to X11, but LO is still usable. > > Forcing LO to run on XWayland would be quite a "radical" step, and not what > other users may be expecting. (I suppose that while Plasma Wayland has > matured a lot over the last years, choosing to run Plasma X11 is still what > some do whose primary goal is to avoid odd Wayland-specific issues. Others > explicitly want Wayland and might not be happy about it silently "not being > used" by some apps.) > > One aspect is also that disabling Qt's wayland QPA plugin by default would > also mean that LO no longer gets used/tested with it - meaning that other > potential issues are presumably not reported and fixed either. > > So in my opinion, forcing to run on X11 would require very strong reasons. > (As I said, the experience I get in my setup isn't that bad, maybe would be > useful to know more exactly what is causing the difference). > > I think one could also argue that the qt6/kf6 VCL plugin shouldn't be used > by default at all, but the gtk3 one instead (which can be forced by using > SAL_USE_VCLPLUGIN=gtk3), because it's the most mature one on Linux. > > Of course, any help to further analyze and fix the issue are more than > welcome. After all, LO is an open source project that welcomes contributions: > https://www.libreoffice.org/community/get-involved/ > > > I'm currently resorting to launching LibreOffice from the terminal every > > time so I can pass the QT_QPA_PLATFORM=xcb envar ONLY to LibreOffice, but I > > don't think that's a reasonable solution. LibreOffice should default to X11 > > until the Wayland backend isn't broken. > > If you don't want to manually set the environment variable every time, one > approach could be to modify the LibreOffice shell wrapper and set the > environment variable there. > Or, as mentioned above, set SAL_USE_VCLPLUGIN=gtk3 in your ~/.bashrc or > similar. > > Operating System: Debian GNU/Linux 12 > KDE Plasma Version: 6.3.0 > KDE Frameworks Version: 6.10.0 > Qt Version: 6.7.2 > Kernel Version: 6.12.12-amd64 (64-bit) > Graphics Platform: Wayland > Processors: 32 × 13th Gen Intel® Core™ i9-13900HX > Memory: 62.5 GiB of RAM > Graphics Processor 1: Intel® Graphics > Graphics Processor 2: NVIDIA GeForce RTX 4060 Laptop GPU > Manufacturer: TUXEDO > Product Name: TUXEDO Gemini Gen2 > > Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: 8710a20fabcb8892d8f1f2ae917101028db61e39 > CPU threads: 32; OS: Linux 6.12; UI render: default; VCL: qt6 (cairo+wayland) > Locale: en-GB (en_GB.UTF-8); UI: en-US > Calc: threaded From my testing it seems to happen only on RPM-based distros. Not sure if others can reproduce.
(In reply to ppaanncchhoo507 from comment #74) > (In reply to Michael Weghorn from comment #52) > > (In reply to danileon95 from comment #51) > > > This bug makes LibreOffice **unusable** on a Wayland session. I'm on a > > > high-end system with a Ryzen 5800X and an RTX 4070Ti Super, on the latest > > > driver, and trying to scroll through a 20-something page document is > > > unusable, and I'm not being hyperbolic, the program just cannot be used like > > > this. > > > > > > I won't pretend to know why this issue is taking so long to fix, but I do > > > have a question. Why not disable Wayland support by default if it's a known > > > fact that it's broken? Then re-enable it once it's not broken? > > > > The experience seems to differ, depending on unknown factors. For example, > > in my setup (s. below for system details), there is a clearly noticeable > > (and annoying) lag on Wayland as compared to X11, but LO is still usable. > > > > Forcing LO to run on XWayland would be quite a "radical" step, and not what > > other users may be expecting. (I suppose that while Plasma Wayland has > > matured a lot over the last years, choosing to run Plasma X11 is still what > > some do whose primary goal is to avoid odd Wayland-specific issues. Others > > explicitly want Wayland and might not be happy about it silently "not being > > used" by some apps.) > > > > One aspect is also that disabling Qt's wayland QPA plugin by default would > > also mean that LO no longer gets used/tested with it - meaning that other > > potential issues are presumably not reported and fixed either. > > > > So in my opinion, forcing to run on X11 would require very strong reasons. > > (As I said, the experience I get in my setup isn't that bad, maybe would be > > useful to know more exactly what is causing the difference). > > > > I think one could also argue that the qt6/kf6 VCL plugin shouldn't be used > > by default at all, but the gtk3 one instead (which can be forced by using > > SAL_USE_VCLPLUGIN=gtk3), because it's the most mature one on Linux. > > > > Of course, any help to further analyze and fix the issue are more than > > welcome. After all, LO is an open source project that welcomes contributions: > > https://www.libreoffice.org/community/get-involved/ > > > > > I'm currently resorting to launching LibreOffice from the terminal every > > > time so I can pass the QT_QPA_PLATFORM=xcb envar ONLY to LibreOffice, but I > > > don't think that's a reasonable solution. LibreOffice should default to X11 > > > until the Wayland backend isn't broken. > > > > If you don't want to manually set the environment variable every time, one > > approach could be to modify the LibreOffice shell wrapper and set the > > environment variable there. > > Or, as mentioned above, set SAL_USE_VCLPLUGIN=gtk3 in your ~/.bashrc or > > similar. > > > > Operating System: Debian GNU/Linux 12 > > KDE Plasma Version: 6.3.0 > > KDE Frameworks Version: 6.10.0 > > Qt Version: 6.7.2 > > Kernel Version: 6.12.12-amd64 (64-bit) > > Graphics Platform: Wayland > > Processors: 32 × 13th Gen Intel® Core™ i9-13900HX > > Memory: 62.5 GiB of RAM > > Graphics Processor 1: Intel® Graphics > > Graphics Processor 2: NVIDIA GeForce RTX 4060 Laptop GPU > > Manufacturer: TUXEDO > > Product Name: TUXEDO Gemini Gen2 > > > > Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community > > Build ID: 8710a20fabcb8892d8f1f2ae917101028db61e39 > > CPU threads: 32; OS: Linux 6.12; UI render: default; VCL: qt6 (cairo+wayland) > > Locale: en-GB (en_GB.UTF-8); UI: en-US > > Calc: threaded > > From my testing it seems to happen only on RPM-based distros. Not sure if > others can reproduce. nevermind, on the latest 25.2 update to libreoffice it happens on ubuntu now. I will need to run this with a debugger....
(In reply to ppaanncchhoo507 from comment #75) > (In reply to ppaanncchhoo507 from comment #74) > > (In reply to Michael Weghorn from comment #52) > > > (In reply to danileon95 from comment #51) > > > > This bug makes LibreOffice **unusable** on a Wayland session. I'm on a > > > > high-end system with a Ryzen 5800X and an RTX 4070Ti Super, on the latest > > > > driver, and trying to scroll through a 20-something page document is > > > > unusable, and I'm not being hyperbolic, the program just cannot be used like > > > > this. > > > > > > > > I won't pretend to know why this issue is taking so long to fix, but I do > > > > have a question. Why not disable Wayland support by default if it's a known > > > > fact that it's broken? Then re-enable it once it's not broken? > > > > > > The experience seems to differ, depending on unknown factors. For example, > > > in my setup (s. below for system details), there is a clearly noticeable > > > (and annoying) lag on Wayland as compared to X11, but LO is still usable. > > > > > > Forcing LO to run on XWayland would be quite a "radical" step, and not what > > > other users may be expecting. (I suppose that while Plasma Wayland has > > > matured a lot over the last years, choosing to run Plasma X11 is still what > > > some do whose primary goal is to avoid odd Wayland-specific issues. Others > > > explicitly want Wayland and might not be happy about it silently "not being > > > used" by some apps.) > > > > > > One aspect is also that disabling Qt's wayland QPA plugin by default would > > > also mean that LO no longer gets used/tested with it - meaning that other > > > potential issues are presumably not reported and fixed either. > > > > > > So in my opinion, forcing to run on X11 would require very strong reasons. > > > (As I said, the experience I get in my setup isn't that bad, maybe would be > > > useful to know more exactly what is causing the difference). > > > > > > I think one could also argue that the qt6/kf6 VCL plugin shouldn't be used > > > by default at all, but the gtk3 one instead (which can be forced by using > > > SAL_USE_VCLPLUGIN=gtk3), because it's the most mature one on Linux. > > > > > > Of course, any help to further analyze and fix the issue are more than > > > welcome. After all, LO is an open source project that welcomes contributions: > > > https://www.libreoffice.org/community/get-involved/ > > > > > > > I'm currently resorting to launching LibreOffice from the terminal every > > > > time so I can pass the QT_QPA_PLATFORM=xcb envar ONLY to LibreOffice, but I > > > > don't think that's a reasonable solution. LibreOffice should default to X11 > > > > until the Wayland backend isn't broken. > > > > > > If you don't want to manually set the environment variable every time, one > > > approach could be to modify the LibreOffice shell wrapper and set the > > > environment variable there. > > > Or, as mentioned above, set SAL_USE_VCLPLUGIN=gtk3 in your ~/.bashrc or > > > similar. > > > > > > Operating System: Debian GNU/Linux 12 > > > KDE Plasma Version: 6.3.0 > > > KDE Frameworks Version: 6.10.0 > > > Qt Version: 6.7.2 > > > Kernel Version: 6.12.12-amd64 (64-bit) > > > Graphics Platform: Wayland > > > Processors: 32 × 13th Gen Intel® Core™ i9-13900HX > > > Memory: 62.5 GiB of RAM > > > Graphics Processor 1: Intel® Graphics > > > Graphics Processor 2: NVIDIA GeForce RTX 4060 Laptop GPU > > > Manufacturer: TUXEDO > > > Product Name: TUXEDO Gemini Gen2 > > > > > > Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community > > > Build ID: 8710a20fabcb8892d8f1f2ae917101028db61e39 > > > CPU threads: 32; OS: Linux 6.12; UI render: default; VCL: qt6 (cairo+wayland) > > > Locale: en-GB (en_GB.UTF-8); UI: en-US > > > Calc: threaded > > > > From my testing it seems to happen only on RPM-based distros. Not sure if > > others can reproduce. > > nevermind, on the latest 25.2 update to libreoffice it happens on ubuntu > now. I will need to run this with a debugger.... given that the problem is that rendering takes too long while scrolling, i suspect the issue to be the use of software rendering instead of hardware acceleration
(In reply to ppaanncchhoo507 from comment #76) > (In reply to ppaanncchhoo507 from comment #75) > > (In reply to ppaanncchhoo507 from comment #74) > > > (In reply to Michael Weghorn from comment #52) > > > > (In reply to danileon95 from comment #51) > > > > > This bug makes LibreOffice **unusable** on a Wayland session. I'm on a > > > > > high-end system with a Ryzen 5800X and an RTX 4070Ti Super, on the latest > > > > > driver, and trying to scroll through a 20-something page document is > > > > > unusable, and I'm not being hyperbolic, the program just cannot be used like > > > > > this. > > > > > > > > > > I won't pretend to know why this issue is taking so long to fix, but I do > > > > > have a question. Why not disable Wayland support by default if it's a known > > > > > fact that it's broken? Then re-enable it once it's not broken? > > > > > > > > The experience seems to differ, depending on unknown factors. For example, > > > > in my setup (s. below for system details), there is a clearly noticeable > > > > (and annoying) lag on Wayland as compared to X11, but LO is still usable. > > > > > > > > Forcing LO to run on XWayland would be quite a "radical" step, and not what > > > > other users may be expecting. (I suppose that while Plasma Wayland has > > > > matured a lot over the last years, choosing to run Plasma X11 is still what > > > > some do whose primary goal is to avoid odd Wayland-specific issues. Others > > > > explicitly want Wayland and might not be happy about it silently "not being > > > > used" by some apps.) > > > > > > > > One aspect is also that disabling Qt's wayland QPA plugin by default would > > > > also mean that LO no longer gets used/tested with it - meaning that other > > > > potential issues are presumably not reported and fixed either. > > > > > > > > So in my opinion, forcing to run on X11 would require very strong reasons. > > > > (As I said, the experience I get in my setup isn't that bad, maybe would be > > > > useful to know more exactly what is causing the difference). > > > > > > > > I think one could also argue that the qt6/kf6 VCL plugin shouldn't be used > > > > by default at all, but the gtk3 one instead (which can be forced by using > > > > SAL_USE_VCLPLUGIN=gtk3), because it's the most mature one on Linux. > > > > > > > > Of course, any help to further analyze and fix the issue are more than > > > > welcome. After all, LO is an open source project that welcomes contributions: > > > > https://www.libreoffice.org/community/get-involved/ > > > > > > > > > I'm currently resorting to launching LibreOffice from the terminal every > > > > > time so I can pass the QT_QPA_PLATFORM=xcb envar ONLY to LibreOffice, but I > > > > > don't think that's a reasonable solution. LibreOffice should default to X11 > > > > > until the Wayland backend isn't broken. > > > > > > > > If you don't want to manually set the environment variable every time, one > > > > approach could be to modify the LibreOffice shell wrapper and set the > > > > environment variable there. > > > > Or, as mentioned above, set SAL_USE_VCLPLUGIN=gtk3 in your ~/.bashrc or > > > > similar. > > > > > > > > Operating System: Debian GNU/Linux 12 > > > > KDE Plasma Version: 6.3.0 > > > > KDE Frameworks Version: 6.10.0 > > > > Qt Version: 6.7.2 > > > > Kernel Version: 6.12.12-amd64 (64-bit) > > > > Graphics Platform: Wayland > > > > Processors: 32 × 13th Gen Intel® Core™ i9-13900HX > > > > Memory: 62.5 GiB of RAM > > > > Graphics Processor 1: Intel® Graphics > > > > Graphics Processor 2: NVIDIA GeForce RTX 4060 Laptop GPU > > > > Manufacturer: TUXEDO > > > > Product Name: TUXEDO Gemini Gen2 > > > > > > > > Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community > > > > Build ID: 8710a20fabcb8892d8f1f2ae917101028db61e39 > > > > CPU threads: 32; OS: Linux 6.12; UI render: default; VCL: qt6 (cairo+wayland) > > > > Locale: en-GB (en_GB.UTF-8); UI: en-US > > > > Calc: threaded > > > > > > From my testing it seems to happen only on RPM-based distros. Not sure if > > > others can reproduce. > > > > nevermind, on the latest 25.2 update to libreoffice it happens on ubuntu > > now. I will need to run this with a debugger.... > > given that the problem is that rendering takes too long while scrolling, i > suspect the issue to be the use of software rendering instead of hardware > acceleration if i disable hardware acceleration scrolling slowly becomes smoother. so maybe it's a graphics api issue in QT?
(In reply to ppaanncchhoo507 from comment #77) > if i disable hardware acceleration scrolling slowly becomes smoother. so > maybe it's a graphics api issue in QT? My guess would be that maybe for some reason, more (scroll?) events are getting generated on Wayland (and maybe also depending on whether or not hardware acceleration is enabled?), so repainting is triggered more often (and that takes time). But that's just a guess and I haven't verified whether it's actually the case.
on my machine, I cannot see any speed differences when scrolling in a word document in dependency of hardware accel. on or off. System: Operating System: openSUSE Tumbleweed 20250428 KDE Plasma Version: 6.3.80 KDE Frameworks Version: 6.14.0 Qt Version: 6.9.0 Kernel Version: 6.14.4-1-default (64-bit) Graphics Platform: Wayland Processors: 20 × 13th Gen Intel® Core™ i7-13700H Memory: 64 GiB of RAM (62.5 GiB usable) Graphics Processor: Intel® Iris® Xe Graphics Manufacturer: TUXEDO Product Name: TUXEDO InfinityBook Pro Gen8 (MK1)
Created attachment 200656 [details] test file 1 (In reply to Michael Weghorn from comment #78) > (In reply to ppaanncchhoo507 from comment #77) > > if i disable hardware acceleration scrolling slowly becomes smoother. so > > maybe it's a graphics api issue in QT? > > My guess would be that maybe for some reason, more (scroll?) events are > getting generated on Wayland (and maybe also depending on whether or not > hardware acceleration is enabled?), so repainting is triggered more often > (and that takes time). But that's just a guess and I haven't verified > whether it's actually the case. what i had said earlier reverses if i set my computer power profile to performance. if i use a second monitor, LibreOffice has no scrolling issues at all on the second monitor regardless of whether hardware acceleration is on or off the second monitor uses an nvidia gpu and the primary monitor uses an amd gpu since i use a laptop with an amd cpu so the scrolling issues only show up on the primary monitor driven by an amd gpu. the secondary monitor is running at 100 hz, 1920x1080 with 100% scaling. Secondary monitor is running at the same resolution but at 165hz and with 125% scaling. Operating System: Ubuntu 24.04 KDE Plasma Version: 5.27.12 KDE Frameworks Version: 5.115.0 Qt Version: 5.15.13 Kernel Version: 6.11.0-24-generic (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 5600H with Radeon Graphics Memory: 22.3 GiB of RAM Graphics Processor: AMD Radeon Graphics, Nvidia RTX 3060 Mobile System Version: Legion 5 15ACH6H
Created attachment 200657 [details] test file 2 attached second test tile, testing was done in both files and effects are more pronounced in the second file
(In reply to ppaanncchhoo507 from comment #80) > Created attachment 200656 [details] > test file 1 > > (In reply to Michael Weghorn from comment #78) > > (In reply to ppaanncchhoo507 from comment #77) > > > if i disable hardware acceleration scrolling slowly becomes smoother. so > > > maybe it's a graphics api issue in QT? > > > > My guess would be that maybe for some reason, more (scroll?) events are > > getting generated on Wayland (and maybe also depending on whether or not > > hardware acceleration is enabled?), so repainting is triggered more often > > (and that takes time). But that's just a guess and I haven't verified > > whether it's actually the case. > > what i had said earlier reverses if i set my computer power profile to > performance. > > if i use a second monitor, LibreOffice has no scrolling issues at all on the > second monitor regardless of whether hardware acceleration is on or off > > the second monitor uses an nvidia gpu and the primary monitor uses an amd > gpu since i use a laptop with an amd cpu > > > so the scrolling issues only show up on the primary monitor driven by an amd > gpu. > > the secondary monitor is running at 100 hz, 1920x1080 with 100% scaling. > Secondary monitor is running at the same resolution but at 165hz and with > 125% scaling. > > Operating System: Ubuntu 24.04 > KDE Plasma Version: 5.27.12 > KDE Frameworks Version: 5.115.0 > Qt Version: 5.15.13 > Kernel Version: 6.11.0-24-generic (64-bit) > Graphics Platform: Wayland > Processors: 12 × AMD Ryzen 5 5600H with Radeon Graphics > Memory: 22.3 GiB of RAM > Graphics Processor: AMD Radeon Graphics, Nvidia RTX 3060 Mobile > System Version: Legion 5 15ACH6H setting the computer for performance included pressing fn+q on the keyboard to change the performance level at the bios level. when i changed performance settings i did it from both kde and the keyboard