https://bugs.documentfoundation.org/show_bug.cgi?id=106154
--- Comment #24 from Jan-Marek Glogowski <glo...@fbihome.de> ---
So for some reason in your profile, when calling Dialog::Execute, LO processes
a delayed UserEvent generated by BackingWindow::dispatchURL called from
somewhere earlier.
UserEvents have the highest priority in LO, and this adds a whooping 800ms to
the 1.8s of opening the dialog. The dialog generation is actually just 600ms,
so it's faster then in my debug build. I've never seen this in my traces - no
idea, what's going on.
But generally opening the URL should probably be converted to an Idle, or it
should run the scheduler for UI updates.
A single operation with 800ms on your HW is way too long and the priority of
the file open operation is also way too high. Might be Ok, if there is no
document yet open, so the user can't interact in any sensible way… well
actually it's not.
Then there is the "first right click" delay, which initializes all macOS
spelling and grammar checking engines for all languages, which currently is 280
for me. It's just once, but it takes 3.5s in my debug build. Changing this to
an on-demand code, or a thread will be some work. I guess all other OS don't
offer so many engines, or the initialization is cheaper. Never seen this
either.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
