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. ***