I have been testing the very delayed opening specifically using attachment 160988 [details], but this has been something I have noticed in general for a while on my Ubuntu 16.04 computer. The step to reproduce is just to start LO and open a document from the start center. It takes a fairly long time to open. I normally do this from the "welcome page" showing the recently opened documents. You can consistently speed it up by either starting a new document, or double-clicking to start two instances of that same document. The second instance will come up instantly. Steps to reproduce: 1.) Close all open documents, so that you are at the greeting page that shows you a grid of the recently opened files. 2.) open one of those files. Notice that it very slowly loads one. 3.) close the document. Open it again, and then attempt another open while it is loading. The second attempt will open almost immediately, and then soon after the first will finish. Bisected to LO 6.4 commit 058c406c1610df7e557b9405619388465d3f056b author Corentin Noël gtk3: Depend on the window stylecontext I really noticed this on my Ubunu 16.04 computer. I didn't notice it on my Ubuntu 20.04 computer. I did the bibisect on my 16.04 computer and it clearly led to this commit. I was recently debugging this document using SAL_USE_VCLPLUGIN=gen and the document opened immediately. Confirmed the same with is true at the bad bibisect point. This is probably a duplicate of bug 128439, but it is worded very differently. The same behaviour seems to be described in bug 133370 comment 10.
My 16.04 Ubuntu is 64bit, running on a Dell latitude E5430 with 8GB of RAM. I do most of my libreoffice compiling and final commits from it, so it is definitely still a decent machine. My 20.04 is on a slightly faster E6540 - just one generation newer and the same RAM.
(In reply to Justin L from comment #0) > This is probably a duplicate of bug 128439, but it is worded very > differently. > The same behaviour seems to be described in bug 133370 comment 10. Not a duplicate... my report is actually about something else..
For me, it takes the longest time with gen backend: 10 seconds. With gtk3 and kf5 it takes less than 3 seconds. Justin: can you re-test? Arch Linux 64-bit Version: 7.1.0.0.alpha1+ Build ID: bd3aeaefff5e7bdef10c4702d1f388083557614e CPU threads: 8; OS: Linux 5.9; UI render: default; VCL: kf5 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 15 November 2020
(In reply to Buovjaga from comment #3) > For me, it takes the longest time with gen backend: 10 seconds. With gtk3 > and kf5 it takes less than 3 seconds. Correction: I forgot to deactivate Skia/Vulkan on gen, so that was the cause of the delay. But regarding the original topic, ~3 seconds doesn't seem to be a big delay.
I don't think I see a problem here, does it make any difference to e.g. replace the gtk_icon_theme_lookup_icon_for_scale calls back to gtk_icon_theme_lookup_icon ?
I don't have the 16.04 machine any more. It now is running 20.04, and I haven't noticed it any more on 20.04. (I am noticing a delay in ctrl-o to get a file open dialog open, but again only on this machine. So it must be something else going on.)