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
Created attachment 192924 [details] Demonstration video - Writer 24.2
Created attachment 192925 [details] Demonstration video - Calc 24.2
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.
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.
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).
Created attachment 200412 [details] Screenshot from Sysprof 48's flame graph - global
Created attachment 200413 [details] Screenshot from Sysprof 48's flame graph - zoomed in