Description: LibreOffice apparently does not wait until window maximization has been set (if needed) before painting the window's components and showing the window. See attached demonstration video. Steps to Reproduce: 1. Unmaximize any libreoffice app window (Writer or Calc, for example), and set some size 2. Quit the app, launch it again 3. Maximize the app's window 4. Quit the app, launch it again Actual Results: The window gets maximized but only after being shown, resulting in a visual glitch where you see the scrollbars in the middle of the window where the "unmaximized, but remembered size" state would be, and then the scrollbars move into their final position a fraction of a second after the window has been correctly maximized. Expected Results: Execute the show() (or show_all() command, or whatever it might be called) on the window only once the window width, height, AND maximization state have been set, so that it can be painted in one shot without any jank. Reproducible: Always User Profile Reset: Yes Additional Info: It happens both on Wayland and Xorg/X11, and has been happening with all LibreOffice versions I can remember.
Created attachment 186769 [details] demonstration video This happens both on Intel and AMD open source graphics drivers; it might be easier to trigger with older hardware, but even recent (less than 5 years old) 8th-generation Intel graphics with Wayland can trigger the issue.
Oh yeah, I forgot to mention I'm running the latest stable version from Fedora 38: Version: 7.5.2.2 (X86_64) Build ID: 50(Build:2) CPU threads: 8; OS: Linux 6.2; UI render: default; VCL: gtk3 Calc: threaded (...but it also happened in the flatpak version from flathub) I would guess this might be an "easyHack" in terms of complexity, maybe it's just the ordering of the operations.
A note for testers who may have a problem reproducing this under Wayland (especially if you're running a distro that patches mutter for triple-buffering, like Ubuntu): today for some reason the issue didn't seem to manifest itself at first, so I logged out of the GNOME Wayland session and logged into the GNOME Xorg session, reproduced the issue there, logged out and into the Wayland session again and... for some reason, the issue now started occurring under Wayland again! At least for a while. In any case, the issue seems to be much easier to trigger & observe under Xorg/X11 than Wayland, so when testing a potential fix, it should be checked there too (just to rule out the possibility of the Wayland session suddenly not exhibiting the behavior, unrelated to the code)
I think I've seen this and while it's difficult to make out, I sort of see it flash by quickly while testing just now. Arch Linux 64-bit, X11 Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 39b25518ce96a50f54459f681edcb95057507251 CPU threads: 8; OS: Linux 6.3; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 12 May 2023
(In reply to Buovjaga from comment #4) > I think I've seen this and while it's difficult to make out, I sort of see > it flash by quickly while testing just now. > > Arch Linux 64-bit, X11 > Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community > Build ID: 39b25518ce96a50f54459f681edcb95057507251 > CPU threads: 8; OS: Linux 6.3; UI render: default; VCL: kf5 (cairo+xcb) > Locale: fi-FI (fi_FI.UTF-8); UI: en-US > Calc: threaded > Built on 12 May 2023 I promise you to test on dbg, but is too fast with 16 cores to see any window slow painting.