Bug 160015 - Janky / slow window resizing and redrawing under Wayland
Summary: Janky / slow window resizing and redrawing under Wayland
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All Linux (All)
: low minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: perf
Depends on:
Blocks: RenderContext Flickering-UI Performance
  Show dependency treegraph
 
Reported: 2024-03-04 02:54 UTC by Jeff Fortin Tam
Modified: 2025-04-20 01:24 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Demonstration video - Writer 24.2 (1.71 MB, video/mp4)
2024-03-04 02:56 UTC, Jeff Fortin Tam
Details
Demonstration video - Calc 24.2 (3.35 MB, video/mp4)
2024-03-04 02:56 UTC, Jeff Fortin Tam
Details
Sysprof capture - resizing Calc 25.2 GTK3 Cairo on GNOME 48 on a 4K screen (3.55 MB, application/x-xz)
2025-04-20 01:22 UTC, Jeff Fortin Tam
Details
Screenshot from Sysprof 48's flame graph - global (1.04 MB, image/png)
2025-04-20 01:23 UTC, Jeff Fortin Tam
Details
Screenshot from Sysprof 48's flame graph - zoomed in (961.05 KB, image/png)
2025-04-20 01:24 UTC, Jeff Fortin Tam
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff Fortin Tam 2024-03-04 02:54:49 UTC
Description:
LibreOffice applications (I've tested at least Calc and Writer) are very slow to resize and redraw their windows on Linux, even under a well-optimized Wayland GNOME 45.4 and open source Mesa drivers for my AMD Radeon R9 270.

No other applications (particularly GTK4 apps) have this problem, other apps resize butter-smoothly.

Steps to Reproduce:
Super+middle-click to resize any window without needing to be super precise, otherwise grab the window's edges to resize.

Actual Results:
Laggy and janky resizing, not just of toolbars (bug #127963) but also the document's canvas, statusbar, scrollbars, etc.

Expected Results:
Butter-smooth resizing.


Reproducible: Always


User Profile Reset: No

Additional Info:
Version: 24.2.1.2 (X86_64) / LibreOffice Community
Build ID: db4def46b0453cc22e2d0305797cf981b68ef5ac
CPU threads: 8; OS: Linux 6.7; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Flatpak
Calc: threaded
Comment 1 Jeff Fortin Tam 2024-03-04 02:56:08 UTC
Created attachment 192924 [details]
Demonstration video - Writer 24.2
Comment 2 Jeff Fortin Tam 2024-03-04 02:56:58 UTC
Created attachment 192925 [details]
Demonstration video - Calc 24.2
Comment 3 Stéphane Guillou (stragu) 2024-03-19 14:24:49 UTC
I can already see it in libreoffice-6.0.0.3 with a MetaWindowXwayland window and the gtk2 VCL plugin, as well as with a MetaWindowWayland in:

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 479b5bbe8ca2177ba7574e7aa2308b5d0de1895c
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: CL threaded

Same for gen and kf5 (cairy+wayland) VCL plugin.
Comment 4 Jeff Fortin Tam 2024-09-02 01:55:00 UTC
Unsurprisingly, I also see high CPU usage (70-100%) on one of my CPU cores during resizing (even on a pretty recent laptop), so marking this as blocking #136524 too.
Comment 5 Jeff Fortin Tam 2025-04-20 01:22:37 UTC
Created attachment 200411 [details]
Sysprof capture - resizing Calc 25.2 GTK3 Cairo on GNOME 48 on a 4K screen

Attaching a Sysprof performance profile from LibreOffice 25.2's GTK3 version from Fedora 42's repositories, with all debuginfo symbols installed for the whole of LibreOffice and all the stack (GTK3, Cairo, glib2, and the rest of the graphics stack).

I was not able to see a difference when setting "use Skia" to true (even with the "force Skia" setting) in the advanced / expert experimental settings, it would give the exact same sysprof results. I was not able to test with the GTK4 version, because if I launch "SAL_USE_VCLPLUGIN=gtk4 libreoffice --calc", it crashes with a null pointer as soon as I try to enter an app like Calc or Writer (it doesn't crash at the LibreOffice global home screen, though).

Beyond the fact that it's GTK3 and Cairo (which are not really GPU-accelerated like GTK4 and Skia would be), if you zoom in into one specific area of the sysprof flamegraph you can see a lot of costly stuff happening in VCL's PaintHelper, and ultimately... it still seems to be Cairo?

If Skia should be in use there (while somehow Cairo is showing up) and there's an indication that I did my testing incorrectly, then let me know how I can ensure that Skia is being used (while running Fedora 42's package ideally, because that's the easiest to profile).
Comment 6 Jeff Fortin Tam 2025-04-20 01:23:47 UTC
Created attachment 200412 [details]
Screenshot from Sysprof 48's flame graph - global
Comment 7 Jeff Fortin Tam 2025-04-20 01:24:03 UTC
Created attachment 200413 [details]
Screenshot from Sysprof 48's flame graph - zoomed in