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!

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

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

Same problem as others are experiencing.
It's pretty wired that the severity is "normal" while it makes the program almost unusable in a working environment.

SysInfo:
Operating System: EndeavourOS 
KDE Plasma Version: 6.4.2
KDE Frameworks Version: 6.15.0
Qt Version: 6.9.1
Kernel Version: 6.15.4-arch2-1 (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 PRO 6650U with Radeon Graphics
Memory: 16 GiB of RAM (14.9 GiB usable)
Graphics Processor: AMD Radeon Graphics

Version: 25.2.4.3 (X86_64) / LibreOffice Community
Build ID: 520(Build:3)
CPU threads: 12; OS: Linux 6.15; UI render: default; VCL: kf6 (cairo+wayland)
Locale: it-IT (it_IT.UTF-8); UI: it-IT
25.2.4-2
Calc: threaded

Completely agree with fv905co2k. This is a really bad issue, the program is completely unusable on Wayland sessions. This isn't the UI being a bit laggy, this is the UI basically freezing any time you try to do anything. The program cannot be used in this state.

In line with the previous comments, it is unusable enough so that I have to force it into xwayland by QT_QPA_PLATFORM=xcb with other but less annoying issues.

(In reply to fv905co2k from comment #83)
> Same problem as others are experiencing.
> It's pretty wired that the severity is "normal" while it makes the program
> almost unusable in a working environment.

It doesn't make the program unusable, but the KDE Frameworks UIs. The workaround is to use gtk3, so I think this can stay as normal severity.

I believe it's an issue in the way QT interacts with the graphics stack on Wayland. KDE has rejected this bug and the thing LibreOffice and KDE have in common is QT.

(In reply to ppaanncchhoo507 from comment #87)
> I believe it's an issue in the way QT interacts with the graphics stack on
> Wayland. KDE has rejected this bug and the thing LibreOffice and KDE have in
> common is QT.

That's what Michael believes as well, see comment 13 to 15.

(In reply to fv905co2k from comment #83)
> Same problem as others are experiencing.
> It's pretty wired that the severity is "normal" while it makes the program
> almost unusable in a working environment.
> 
> SysInfo:
> Operating System: EndeavourOS 
> KDE Plasma Version: 6.4.2
> KDE Frameworks Version: 6.15.0
> Qt Version: 6.9.1
> Kernel Version: 6.15.4-arch2-1 (64-bit)
> Graphics Platform: Wayland
> Processors: 12 × AMD Ryzen 5 PRO 6650U with Radeon Graphics
> Memory: 16 GiB of RAM (14.9 GiB usable)
> Graphics Processor: AMD Radeon Graphics
> 
> Version: 25.2.4.3 (X86_64) / LibreOffice Community
> Build ID: 520(Build:3)
> CPU threads: 12; OS: Linux 6.15; UI render: default; VCL: kf6 (cairo+wayland)
> Locale: it-IT (it_IT.UTF-8); UI: it-IT
> 25.2.4-2
> Calc: threaded

Same problem with this configuration too:

Operating System: EndeavourOS 
KDE Plasma Version: 6.4.2
KDE Frameworks Version: 6.15.0
Qt Version: 6.9.1
Kernel Version: 6.15.5-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 4 × Intel® Core™ i5-7260U CPU @ 2.20GHz
Memory: 32 GiB of RAM (31.2 GiB usable)
Graphics Processor: Mesa Intel® Iris® Plus Graphics 640


Version: 25.2.4.3 (X86_64) / LibreOffice Community
Build ID: 520(Build:3)
CPU threads: 4; OS: Linux 6.15; UI render: default; VCL: kf6 (cairo+wayland)
Locale: it-IT (it_IT.UTF-8); UI: it-IT
25.2.4-2
Calc: threaded

Calc does not have this problem. It only seems to occur where there are pages (as in Writer and Impress)

I tried Libreoffice in Sway with qt6 SAL plugin. It's fluid.
Yet another Kwin bug?

Calc is the one where I've been having this problem.

(In reply to Guido Iodice from comment #91)
> I tried Libreoffice in Sway with qt6 SAL plugin. It's fluid.
> Yet another Kwin bug?

I have the same problem in both hyprland and sway, i think its a qt/wayland problem since using either gtk3/wayland or qt/x11 solves the problem

(In reply to Ashley Paul from comment #93)
> (In reply to Guido Iodice from comment #91)
> > I tried Libreoffice in Sway with qt6 SAL plugin. It's fluid.
> > Yet another Kwin bug?
> 
> I have the same problem in both hyprland and sway, i think its a qt/wayland
> problem since using either gtk3/wayland or qt/x11 solves the problem

OK, but LO is the only application that has this problem, all other QTs are fine

I'm having this issue too on a fresh Debian 13 install, running Wayland/KDE. Scrolling through a large Calc spreadsheet using the mouse wheel or by dragging the scroll bar on the far-right of the screen causes horrible lag and eventually unresponsiveness (tested on a 855 column/19 row sheet filled with data in every cell). Using page up/down or the arrow keys does not cause lag and may be a potential workaround for some. Using QT_QPA_PLATFORM=xcb as an environment variable to run LibreOffice in X11 removes the lag for me, so I'm doing that as a workaround for now. Using SAL_USE_VCLPLUGIN=gtk3 fixes the worst of the lag/unresponsiveness, though it's still noticeably slower than using kf6 under X11 when doing things, such as using the page up/down buttons. You're also forced to use the GTK file picker to open/save files when using gtk3, which makes that a non-viable solution for me.

Software/Hardware info:

Operating System: Debian GNU/Linux 13
KDE Plasma Version: 6.3.6
KDE Frameworks Version: 6.13.0
Qt Version: 6.8.2
Kernel Version: 6.12.38+deb13-amd64 (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 5560U with Radeon Graphics
Memory: 16 GiB of RAM (12.6 GiB usable)
Graphics Processor: AMD Radeon Graphics
Manufacturer: AZW
Product Name: SER

LibreOffice info:

Version: 25.2.3.2 (X86_64) / LibreOffice Community
Build ID: 520(Build:2)
CPU threads: 12; OS: Linux 6.12; UI render: default; VCL: kf6 (cairo+wayland)
Locale: en-US (en_US.UTF-8); UI: en-US
Debian package version: 4:25.2.3-2
Calc: threaded

I originally "me too"'d this bug on a Fedora Linux system approximately one year ago, but I now use Arch Linux and am having exactly the same issues as I used to on Fedora. My imperfect workaround for the past year has been to create custom .desktop files in ~/.local/share/applications which set QT_QPA_PLATFORM=xcb. I would love to see this bug finally fixed.

Operating System: Arch Linux 
KDE Plasma Version: 6.4.4
KDE Frameworks Version: 6.17.0
Qt Version: 6.9.1
Kernel Version: 6.15.9-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 22 × Intel® Core™ Ultra 7 155H
Memory: 48 GiB of RAM (46.7 GiB usable)
Graphics Processor: Intel® Arc
Manufacturer: Notebook
Product Name: V54x_6x_TU
System Version: V540TU

Possibly related Qt issue for which at least one commit was merged yesterday (for Qt >= 6.11).

https://bugreports.qt.io/browse/QTBUG-139231 ("Wayland: Optimize scrolling")


I didn't look into it in more detail, though, just skimmed the issue and commit message.

*** Bug 168374 has been marked as a duplicate of this bug. ***

This issue still exists in 2025.

I have several home PCs all with Ubuntu/Debian base (Neon, Kubuntu), KDE 6.4 Wayland and Intel, AMD and Nvidia GPUs - all have this issue (eg. LibreOffice is completely unusable).

However.

I have one install of Fedora 42, with same KDE 6.4, and Wayland - witn Intel GPU that DOES NOT have the issue.

As it seems to me we are collectively none the wiser about the root cause of this issue - since 2023.

Therefore;

I would suggest that this issue may benefit from an online pool, so that we can at least create a matrix of OS/DE/CPU/LO/etc that produces the issue. And narrow down the potential causes to further investigate...

Or is there anyone who knows whats going on?

Thanks,
Andrej

I recently got a new laptop, with AMD graphics. I installed EndeavourOS on it, which defaults to Wayland nowadays. I then installed libreoffice-fresh from the official packages. Then I launched it and, of course, it is completely unusable, just like on my desktop.

**The program does not work and cannot be used for an increasingly large amount of users, by default, with no obvious way to make it usable unless they are advanced users and dig around**. I really think you should make LibreOffice default to xWayland until this is resolved (assuming you care about the program being usable, that is)

(In reply to danileon95 from comment #101)
> **The program does not work and cannot be used for an increasingly large
> amount of users, by default, with no obvious way to make it usable unless
> they are advanced users and dig around**. I really think you should make
> LibreOffice default to xWayland until this is resolved (assuming you care
> about the program being usable, that is)

As mentioned earlier, the experience seems to differ for different users (it's not unusable for me). If qt6/kf6 on Wayland is considered "not good enough", I think the better solution/workaround would be to default to gtk3 instead, which is still the most mature VCL plugin on Linux.
(There are different levels to control that: What LO's internal logic defaults to, what VCL plugins distros package, which ones users install, environment variables,...)

But I think any such discussion/decision should happen in its own bug report as it doesn't contribute to directly analyzing/solving the issue that this report here is about. Please feel free to create a separate bug report to not use qt6 with the Qt wayland QPA plugin if you think that shouldn't be the case. Then, alternatives can be discussed in that ticket, and also whether qt6/kf6 is considered "good enough" on X11/XWayland, or gtk3 should be used everywhere by default,...

What Michael says is true, however it should be acknowledge that the issue reported here is not an edge case, but the default behaviour on Wayland, and as such must be addressed sooner rather than later given most distros now ship wayland by default.

I've redone some test using two different machine. 

One with AMD Radeon iGPU:
Operating System: Fedora Linux 42
KDE Plasma Version: 6.4.5
KDE Frameworks Version: 6.18.0
Qt Version: 6.9.2
Kernel Version: 6.16.9-200.fc42.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 PRO 6650U with Radeon Graphics
Memory: 32 GiB of RAM (30.7 GiB usable)
Graphics Processor: AMD Radeon Graphics

Another with Intel UHD Graphic 620.
Operating System: Fedora Linux 43 beta
KDE Plasma Version: 6.4.5
KDE Frameworks Version: 6.18.0
Qt Version: 6.9.2
Kernel Version: 6.17
Graphics Platform: Wayland
Processors: 8 × Intel i5-8350U
Memory: 16 GiB of RAM
Graphics Processor: Intel UHD Graphic 620

Both laptop have a 1080p 14" screen.

There is a noticeable lag during scrolling with both the kf6 and gtk3 VCL back-ends and this on both machines (more details below). There is no lag when using the xcb backend.

Influencing factors:
====================

- VCL back-ends: the lag is significantly worse using the kf6 over the gtk3 back-end
- Screens: the lag significantly worsen when plugin in an external screen

I'd say that for any Qt/Kf based distro, this make the lag behaviour basically a default, and while usable in case of using a single, reasonably low res, screen, it becomes unusable as soon as using another screen.

I've played around with some of the workarounds mentioned for a while now, but all have significant downsides, so it's kind of a pick-your-poison situation for the time being. I ultimately went back to just dealing with the bug by scrolling with page up and down rather than the scrollbars. I don't think the GTK3 plugin is viable for most people, however. Aside from losing the KDE file picker when using the GTK3 file picker (mentioned in an earlier comment), the GTK3 plugin clashes with KDE's clipboard management somehow, so copy & paste doesn't work outside of the LibreOffice applications literally half the time (this bug isn't present while using kf6); see bug: https://bugs.documentfoundation.org/show_bug.cgi?id=165164

Taskbar grouping is also semi-broken with the GTK3 plugin on KDE. Instances of LibreOffice initially aren't grouped together in the taskbar, but group together after opening/closing any other taskbar program (although they still sometimes don't show a "+" icon to indicate more than 1 instance is present); this doesn't happen when using the kf6 plugin. I also found that while using QT_QPA_PLATFORM=xcb/Xwayland as a workaround, taskbar grouping is broken there, too (more so than with GTK3); if you have LibreOffice Calc pinned to the taskbar and open Calc, it doesn't group itself into the taskbar icon at all and appears as a separate icon, no matter what you do. I don't think either of the taskbar bugs I mentioned are worth fixing or reporting, though; if this thread's bug gets fixed, one shouldn't need to fall back to GTK3 or XWayland at all (unless running the Flatpak).

(In reply to byebyebugaylon from comment #104)

> I also found that
> while using QT_QPA_PLATFORM=xcb/Xwayland as a workaround, taskbar grouping
> is broken there, too

I am using the QT_QPA_PLATFORM=xcb hack, and taskbar grouping works perfectly. Since it's also kf6+xwayland, the file open dialog is KDE-native, too.

Honestly, I already forgot about this bug, simply using the xcb platform seems like  aperfect workaround for the time being.

Here are my specs:

Operating System: Arch Linux
KDE Plasma Version: 6.4.5
KDE Frameworks Version: 6.18.0
Qt Version: 6.9.2
Kernel Version: 6.16.10-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 PRO 6850U with Radeon Graphics
Memory: 16 Gio of RAM (13.4 Gio usable)
Graphics Processor: AMD Radeon Graphics
Manufacturer: LENOVO
Product Name: 21J5000EFR
System Version: ThinkPad P14s Gen 3
I have a 1920x1200 screen

I currently encounter two different bugs related to scrolling:
- A performance issue related to rendering on Writer only, it appends across GTK3, GTK4, QT5 and QT6 on both Xwayland and Wayland (gen works fine)
This bug is less severe with 100% scaling instead of 125%
It appeared with libreoffice writer 25.8.1 update, 25.8.0 and older works fine

- Laggy scrolling with QT5 and QT6 accross all libreoffice apps, only on wayland and with any scaling value different than 100% scaling

Thanks for the additional information.

Can someone of those affected please describe the exact steps to reproduce, and attach a non-confidential sample document to reproduce, and a screencast of the behavior you get with both, native wayland and QT_QPA_PLATFORM=xcb?

By now, I seem to be completely unable to reproduce this on Debian testing with KDE Plasma, using current development versions of both LibreOffice and Qt (qtbase as of commit 109103e69b51b014e4720a70044faee03ad495f8 when running LO while the system otherwise uses Qt 6.9.2 as packaged in Debian).
(Scenario from comment 13 no longer seems problematic while scrolling for me either.)

https://bugreports.qt.io/browse/QTBUG-139231 (contained in current Qt git dev, to become Qt 6.11 one day) was closed as fixed today, so if anybody could do a comparison test with a current development version of Qt to see whether that helps, that would be interesting as well.

Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: bc74f11ee12112237af8e8ba5adbe01198bba06f
CPU threads: 32; OS: Linux 6.16; UI render: default; VCL: qt6 (cairo+wayland)
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: CL threaded

Operating System: Debian GNU/Linux 13
KDE Plasma Version: 6.3.6
KDE Frameworks Version: 6.18.0
Qt Version: 6.9.2
Kernel Version: 6.16.9+deb14-amd64 (64-bit)
Graphics Platform: Wayland
Processors: 32 × 13th Gen Intel® Core™ i9-13900HX
Memory: 64 GiB of RAM (62.5 GiB usable)
Graphics Processor 1: Intel® Graphics
Graphics Processor 2: NVIDIA GeForce RTX 4060 Laptop GPU
Manufacturer: TUXEDO
Product Name: TUXEDO Gemini Gen2

Created attachment 203217 [details]
Scrolling performance with native wayland

Here is a video of the scrolling performance on my system with native wayland.

Created attachment 203218 [details]
Scrolling performance with xcb (xwayland)

Here's a video of the scrolling performance on my system with xcb (xwayland)

Created attachment 203219 [details]
Example text document

Here's the example text document used in both videos

(In reply to Michael Weghorn from comment #107)
> Thanks for the additional information.
> 
> Can someone of those affected please describe the exact steps to reproduce,
> and attach a non-confidential sample document to reproduce, and a screencast
> of the behavior you get with both, native wayland and QT_QPA_PLATFORM=xcb?
> 
> By now, I seem to be completely unable to reproduce this on Debian testing
> with KDE Plasma, using current development versions of both LibreOffice and
> Qt (qtbase as of commit 109103e69b51b014e4720a70044faee03ad495f8 when
> running LO while the system otherwise uses Qt 6.9.2 as packaged in Debian).
> (Scenario from comment 13 no longer seems problematic while scrolling for me
> either.)
> 
> https://bugreports.qt.io/browse/QTBUG-139231 (contained in current Qt git
> dev, to become Qt 6.11 one day) was closed as fixed today, so if anybody
> could do a comparison test with a current development version of Qt to see
> whether that helps, that would be interesting as well.
> 
> Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community
> Build ID: bc74f11ee12112237af8e8ba5adbe01198bba06f
> CPU threads: 32; OS: Linux 6.16; UI render: default; VCL: qt6 (cairo+wayland)
> Locale: en-GB (en_GB.UTF-8); UI: en-US
> Calc: CL threaded
> 
> Operating System: Debian GNU/Linux 13
> KDE Plasma Version: 6.3.6
> KDE Frameworks Version: 6.18.0
> Qt Version: 6.9.2
> Kernel Version: 6.16.9+deb14-amd64 (64-bit)
> Graphics Platform: Wayland
> Processors: 32 × 13th Gen Intel® Core™ i9-13900HX
> Memory: 64 GiB of RAM (62.5 GiB usable)
> Graphics Processor 1: Intel® Graphics
> Graphics Processor 2: NVIDIA GeForce RTX 4060 Laptop GPU
> Manufacturer: TUXEDO
> Product Name: TUXEDO Gemini Gen2

Hello, I have done exactly as requested and attached videos of my scrolling performance with wayland and xcb as well as the text document used in both videos.

I've already posted my specs before, but just in case:
EndeavourOS with KDE Plasma 6.4.5
Ryzen 5800X
Nvidia 4070Ti Super (I have also reproduced this on my AMD graphics laptop)
32 GB RAM
1440p desktop resolution with 125% scaling

In case it isn't clear, in both videos I'm holding the mouse button down as I drag the scroll bar. The Wayland example is completely unresponsive, to the point that it almost looks like I'm not interacting with it again. The xcb example is fully responsive as expected.

Created attachment 203236 [details]
scrolling with xcb

(In reply to Michael Weghorn from comment #107)
> Thanks for the additional information.
> 
> Can someone of those affected please describe the exact steps to reproduce,

1. Open LO calc on a blank new document
2. Start scrolling 😅

> and attach a non-confidential sample document to reproduce, and a screencast
> of the behavior you get with both, native wayland and QT_QPA_PLATFORM=xcb?

Find attached.

One is using xcb with external monitor and fractional scaling - the best, totally smooth
One is using wayland with external monitor and fractional scaling - worse
One is using wayland with external monitor but without fractional scaling - somewhat better than with fractional scaling, but still not smooth, it starts lagging after a few scrolls.

Created attachment 203237 [details]
scrolling - wayland and fractional scaling

Created attachment 203238 [details]
scrolling - wayland without fractional scaling

Created attachment 203239 [details]
wayland - without external screen and without fractional scaling

I've also added this one to show how much better is it if I'm not plugged in to an external screen. You'll in that screencast scrolling looks totally smooth (in actual fact it is possible to observe some small lag when I do a lo of scrolling).

@Michael, is it possible that you see no lags because your test config has a rather powerful desktop processor? I just looked it up and it's at least 3 times as powerful as my laptop one. As a reminder, here is my config:

Operating System: Fedora Linux 42
KDE Plasma Version: 6.4.5
KDE Frameworks Version: 6.18.0
Qt Version: 6.9.2
Kernel Version: 6.16.9-200.fc42.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 PRO 6650U with Radeon Graphics
Memory: 32 GiB of RAM (30.7 GiB usable)
Graphics Processor: AMD Radeon Graphics

Yesterday we got a comment on IRC:

"I just wanted to say that the Qt6 Wayland scrolling but is fixed in Qt6 git, the following commits can be cleanly cherry-piked onto 6.10.0 to fix the issue  09575981885   # Introduce compression 6f25f703fd3   # Optimize scrolling 9dd0d936d66   # Fix scroll end event"

My god, please cherry pick those commits if it does fix it. This bug has been a nightmare, especially since I haven't found a way to open libreoffice with the xcb env var when opening an .odt file from the file browser (The KDE menus don't apply the env var for some reason, so I have to open libreoffice through the terminal to manually set the enc var)

@Gauthier no, I guarantee you that isn't it. Look at the videos I attached, those are recorded on a desktop PC with a ryzen 5800X.

(In reply to danileon95 from comment #119)
> My god, please cherry pick those commits if it does fix it. This bug has
> been a nightmare, especially since I haven't found a way to open libreoffice
> with the xcb env var when opening an .odt file from the file browser (The
> KDE menus don't apply the env var for some reason, so I have to open
> libreoffice through the terminal to manually set the enc var)

While we all share your hope, this is the wrong venue for such a request :)

Thanks all for the additional input.

(In reply to Gauthier from comment #117)
> @Michael, is it possible that you see no lags because your test config has a
> rather powerful desktop processor? I just looked it up and it's at least 3
> times as powerful as my laptop one.

It might be somehow related, but I wouldn't necessarily expect that that's the main reason/problem.


(In reply to Michael Weghorn from comment #107)
> By now, I seem to be completely unable to reproduce this on Debian testing
> with KDE Plasma, using current development versions of both LibreOffice and
> Qt (qtbase as of commit 109103e69b51b014e4720a70044faee03ad495f8 when
> running LO while the system otherwise uses Qt 6.9.2 as packaged in Debian).
> (Scenario from comment 13 no longer seems problematic while scrolling for me
> either.)
> [...]


Results from testing some more, trying to take the additional input from other comments into account, for a scenario similar to the one described in comment 111 (using sample file attachment 203219 [details] with my laptop screen only, resolution set to 1920x1200, 125% display scaling):

There are clear lags when using SAL_USE_VCLPLUGIN=qt5 and Wayland (which is what I was using when I could reproduce earlier, see comment comment 13 and version information in comment 11).

It is much better with qt6 and wayland (current dev version of Qt).

So there seems to be a real improvement somewhere between Qt 5 (Debian-packaged 5.15.17) and Qt 6 dev (to become 6.11 one day).

For me, it's generally not too bad with LO 25.8.1 and kf6 with system Qt (version 6.9.2) either, though.


(In reply to Buovjaga from comment #118)
> Yesterday we got a comment on IRC:
> 
> "I just wanted to say that the Qt6 Wayland scrolling but is fixed in Qt6
> git, the following commits can be cleanly cherry-piked onto 6.10.0 to fix
> the issue  09575981885   # Introduce compression 6f25f703fd3   # Optimize
> scrolling 9dd0d936d66   # Fix scroll end event"

That sounds promising. The best way forward then might indeed for affected people to report back here whether it's better for them as well, once they have a new enough Qt version.

(In reply to danileon95 from comment #119)
> please cherry pick those commits if it does fix it.

As Ilmari mentions in comment 120, this is outside of our control, as LibreOffice uses the system-provided Qt. There was a suggestion to backport to Qt 6.10 upstream, but that was not considered a good idea, see https://codereview.qt-project.org/c/qt/qtbase/+/666461 .

So you'll either have to wait for 6.11 to be released, use the current development version of Qt, or try to convince your distro's Qt maintainers to backport to the distro-packaged Qt. But if upstream Qt deliberately didn't backport, then I'm not sure it's a good idea to try to convince distros to do otherwise.

> This bug has
> been a nightmare, especially since I haven't found a way to open libreoffice
> with the xcb env var when opening an .odt file from the file browser (The
> KDE menus don't apply the env var for some reason, so I have to open
> libreoffice through the terminal to manually set the enc var)

What should presumably work is to right-click on a file of the given type in Dolphin, select "Open with" -> "Other application", then select a script/desktop file that sets the env var and starts the application, and check the "Always open <file type> with the chosen app checkbox.



Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 15e975d4591f28bfa654af08e980a38b53a727bb
CPU threads: 32; OS: Linux 6.16; UI render: default; VCL: qt6 (cairo+wayland)
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded


Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 15e975d4591f28bfa654af08e980a38b53a727bb
CPU threads: 32; OS: Linux 6.16; UI render: default; VCL: qt5 (cairo+wayland)
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded

Version: 25.8.1.1 (X86_64) / LibreOffice Community
Build ID: 580(Build:1)
CPU threads: 32; OS: Linux 6.16; UI render: default; VCL: kf6 (cairo+wayland)
Locale: en-GB (en_GB.UTF-8); UI: en-GB
Debian package version: 4:25.8.1-1
Calc: threaded

(In reply to Michael Weghorn from comment #121)
> (In reply to Buovjaga from comment #118)
> > Yesterday we got a comment on IRC:
> > 
> > "I just wanted to say that the Qt6 Wayland scrolling but is fixed in Qt6
> > git, the following commits can be cleanly cherry-piked onto 6.10.0 to fix
> > the issue  09575981885   # Introduce compression 6f25f703fd3   # Optimize
> > scrolling 9dd0d936d66   # Fix scroll end event"
> 
> That sounds promising. The best way forward then might indeed for affected
> people to report back here whether it's better for them as well, once they
> have a new enough Qt version.

-> setting to NEEDINFO for now. Can one of the affected users please give an update here once you have Qt >= 6.11 or have tried with a current development version of Qt?

(In reply to Michael Weghorn from comment #12)
> Created attachment 192316 [details]
> Hotspot flamegraph of scrolling using scrollbar w/ qt6 on Wayland

Just another idea to keep in mind: Looking at that flamegraph again, it can be seen that the vcl ScollBar's mouse event handling is involved. Whether or not using a native QScrollBar instead would improve the situation is unclear, but might generally be worth a try at least if Qt >= 6.11 isn't going to fully resolve the situation. It depends on quite some other things to be done first in the context of tdf#130857 however.

(In reply to Michael Weghorn from comment #123)
> (In reply to Michael Weghorn from comment #12)
> > Created attachment 192316 [details]
> > Hotspot flamegraph of scrolling using scrollbar w/ qt6 on Wayland
> 
> Just another idea to keep in mind: Looking at that flamegraph again, it can
> be seen that the vcl ScollBar's mouse event handling is involved. Whether or
> not using a native QScrollBar instead would improve the situation is
> unclear, but might generally be worth a try at least if Qt >= 6.11 isn't
> going to fully resolve the situation. It depends on quite some other things
> to be done first in the context of tdf#130857 however.

Although the bug may also be caused by Qt, which proves to be very slow on Wayland, even with the optimisations of the patch linked above, it is fair to say that this bug is present in LibreOffice olny. I use KDE, so I use a lot of Qt applications and no other Qt application has problems with scrolling. So I think something can be done on the LO side.

(In reply to Guido Iodice from comment #124)
> Although the bug may also be caused by Qt, which proves to be very slow on
> Wayland, even with the optimisations of the patch linked above, it is fair
> to say that this bug is present in LibreOffice olny. I use KDE, so I use a
> lot of Qt applications and no other Qt application has problems with
> scrolling. So I think something can be done on the LO side.

Sure, I expect that e.g. document rendering in Writer is more complex (and expensive in terms of CPU load) than what most other Qt applications do, and profiling and trying to optimize that could be another non-trivial approach to pursue. It's always worth looking at all layers involved. It "just" needs somebody to do the work.

(In reply to Buovjaga from comment #118)
> Yesterday we got a comment on IRC:
> 
> "I just wanted to say that the Qt6 Wayland scrolling but is fixed in Qt6
> git, the following commits can be cleanly cherry-piked onto 6.10.0 to fix
> the issue  09575981885   # Introduce compression 6f25f703fd3   # Optimize
> scrolling 9dd0d936d66   # Fix scroll end event"

I confirm that applying those 3 commits on top of Qt 6.10.0 dramatically improves scrolling performances on Wayland (2160p, 150% fractional scaling).

It's still not as buttery smooth as XCB on XWayland, but it makes LO completely usable now (while it simply wasn't before, due to seconds-long freeze when scrolling).

For people on Arch, I've published a qt6-base package on AUR including those 3 patches: https://aur.archlinux.org/pkgbase/qt6-base-scrollfix

(In reply to gilles from comment #126)
> (In reply to Buovjaga from comment #118)
> > Yesterday we got a comment on IRC:
> > 
> > "I just wanted to say that the Qt6 Wayland scrolling but is fixed in Qt6
> > git, the following commits can be cleanly cherry-piked onto 6.10.0 to fix
> > the issue  09575981885   # Introduce compression 6f25f703fd3   # Optimize
> > scrolling 9dd0d936d66   # Fix scroll end event"
> 
> I confirm that applying those 3 commits on top of Qt 6.10.0 dramatically
> improves scrolling performances on Wayland (2160p, 150% fractional scaling).
> 
> It's still not as buttery smooth as XCB on XWayland, but it makes LO
> completely usable now (while it simply wasn't before, due to seconds-long
> freeze when scrolling).
> 
> For people on Arch, I've published a qt6-base package on AUR including those
> 3 patches: https://aur.archlinux.org/pkgbase/qt6-base-scrollfix

Great! I use X11 myself, but still, it is a good news.

(In reply to Guido Iodice from comment #124)
> (In reply to Michael Weghorn from comment #123)
> > (In reply to Michael Weghorn from comment #12)
> > > Created attachment 192316 [details]
> > > Hotspot flamegraph of scrolling using scrollbar w/ qt6 on Wayland
> > 
> > Just another idea to keep in mind: Looking at that flamegraph again, it can
> > be seen that the vcl ScollBar's mouse event handling is involved. Whether or
> > not using a native QScrollBar instead would improve the situation is
> > unclear, but might generally be worth a try at least if Qt >= 6.11 isn't
> > going to fully resolve the situation. It depends on quite some other things
> > to be done first in the context of tdf#130857 however.
> 
> Although the bug may also be caused by Qt, which proves to be very slow on
> Wayland, even with the optimisations of the patch linked above, it is fair
> to say that this bug is present in LibreOffice olny. I use KDE, so I use a
> lot of Qt applications and no other Qt application has problems with
> scrolling. So I think something can be done on the LO side.

This.
Optimization on QT6 can be beneficial, but the issue lies within LibreOffice, as it's the only application experiencing this problem.

My solution was to start using OnlyOffice while waiting for the bug to be fixed.

(In reply to Michael Weghorn from comment #125)
> (In reply to Guido Iodice from comment #124)
> > Although the bug may also be caused by Qt, which proves to be very slow on
> > Wayland, even with the optimisations of the patch linked above, it is fair
> > to say that this bug is present in LibreOffice olny. I use KDE, so I use a
> > lot of Qt applications and no other Qt application has problems with
> > scrolling. So I think something can be done on the LO side.
> 
> Sure, I expect that e.g. document rendering in Writer is more complex (and
> expensive in terms of CPU load) than what most other Qt applications do, and
> profiling and trying to optimize that could be another non-trivial approach
> to pursue. It's always worth looking at all layers involved. It "just" needs
> somebody to do the work.

(In reply to fv905co2k from comment #128)
> (In reply to Guido Iodice from comment #124)
> > (In reply to Michael Weghorn from comment #123)
> > > (In reply to Michael Weghorn from comment #12)
> > > > Created attachment 192316 [details]
> > > > Hotspot flamegraph of scrolling using scrollbar w/ qt6 on Wayland
> > > 
> > > Just another idea to keep in mind: Looking at that flamegraph again, it can
> > > be seen that the vcl ScollBar's mouse event handling is involved. Whether or
> > > not using a native QScrollBar instead would improve the situation is
> > > unclear, but might generally be worth a try at least if Qt >= 6.11 isn't
> > > going to fully resolve the situation. It depends on quite some other things
> > > to be done first in the context of tdf#130857 however.
> > 
> > Although the bug may also be caused by Qt, which proves to be very slow on
> > Wayland, even with the optimisations of the patch linked above, it is fair
> > to say that this bug is present in LibreOffice olny. I use KDE, so I use a
> > lot of Qt applications and no other Qt application has problems with
> > scrolling. So I think something can be done on the LO side.
> 
> This.
> Optimization on QT6 can be beneficial, but the issue lies within
> LibreOffice, as it's the only application experiencing this problem.
> 
> My solution was to start using OnlyOffice while waiting for the bug to be
> fixed.

To add to this: 

While @Michael has got a good point in terms of LO being more heavy on rendering than many other apps, the fact that this issue occurs even on an empty document (either an empty spreadsheet or an empty writer document where you just create lots of blank pages and then scroll through) really feels like there is something going wrong that is quite specific to LO.

Update: the situation has drastically improved with the latest update: it still doesn't work, but now it's barely usable.

Same Libreoffice version on both machines:
Version: 25.8.2.1 (X86_64) / LibreOffice Community
Build ID: 580(Build:1)
CPU threads: 4; OS: Linux 6.17; UI render: default; VCL: kf6 (cairo+wayland)
Locale: it-IT (it_IT.UTF-8); UI: it-IT
25.8.2-1
Calc: threaded

Machine 1 is a NUC, operated with a mouse and keyboard. Zooming using the keyboard and mouse wheel works great. However, moving the scroll bar—either by blocking the mouse wheel and moving the mouse up and down, or by clicking and dragging the scroll bar—causes the program to freeze.

Machine 1 specs:
Operating System: EndeavourOS 
KDE Plasma Version: 6.4.5
KDE Frameworks Version: 6.19.0
Qt Version: 6.10.0
Kernel Version: 6.17.1-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 4 × Intel® Core™ i5-7260U CPU @ 2.20GHz
Memory: 32 GiB of RAM (31.2 GiB usable)
Graphics Processor: Mesa Intel® Iris® Plus Graphics 640

Machine 2 is a laptop. Zooming and scrolling cause the application to freeze, whether using touchpad gestures or the LibreOffice interface. However, I can now navigate through the document using the keyboard without any graphical artifacts.

Machine 2 specs:
Operating System: EndeavourOS 
KDE Plasma Version: 6.4.5
KDE Frameworks Version: 6.19.0
Qt Version: 6.10.0
Kernel Version: 6.17.1-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 PRO 6650U with Radeon Graphics
Memory: 16 GiB of RAM (14.9 GiB usable)
Graphics Processor: AMD Radeon Graphics

*** Bug 168875 has been marked as a duplicate of this bug. ***