Description: I'm using LibO 6.3.3.2 on a machine with a somehow outdated graphics card on a Kubuntu linux 19.10 system (deb packages from TDF). While the application is generally usable, the context menu is extremely slow. When you move the mouse over it, there is a notable delay by which the highlighted entry follows the mouse pointer. The regular (top of window) menus in the menubar don't have this issue. The slowlyness is present regardless of whether opengl rendering is enabled or not. Steps to Reproduce: Open application (e.g. with a drawing), draw something, right click on some element to get the contextual menu, move the highlighted line of the menu up and down with the mouse. Actual Results: The highlighted entry lags after the mouse pointer. Expected Results: The highlighted entry should move almost instantaneously under the mouse Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: [Information automatically included from LibreOffice] Locale: en-US Module: PresentationDocument [Information guessed from browser] OS: Linux (All) OS is 64bit: yes
On pc Debian x86-64 with LO master sources updated today or with LO Debian package 6.3.3 + kf5 rendering, I don't reproduce this. I launched Draw, created a simple rectangle, then right clicked on rectangle and moused over the different items, no slowliness.
Thank you for reporting the bug. To be certain the reported issue is not related to corruption in the user profile, could you please reset your Libreoffice profile ( https://wiki.documentfoundation.org/UserProfile ) and re-test? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the issue is still present
Since kf5 rendering is quite in development in LO, you can give a try to a different rendering. Could you make this test: - launch command line - export SAL_USE_VCLPLUGIN=gen - launch LO from command line and give a new try?
The Menubar is a native QMenu widget, while the popup menus aren't. Menu drawing in VCL is conflicting with the way Qt draws menus, so there is a lot of clipping and reversing the way VCL paints the menu with temporary images etc. I guess this is the origin of the problem. Solution: someone has to implement popup menus with native QMenus and I guess this will solve the problem.
Michael: since it concerns QT/KF5, thought you might be interested in this one.
(In reply to Julien Nabet from comment #5) > Michael: since it concerns QT/KF5, thought you might be interested in this > one. Thanks, I cannot reproduce here (probably due to faster hardware), and have nothing to add to comment 4 at this point (was thinking the same when reading the bug title).
Indeed the issue is seen on older hardware: a DELL precision T5400 workstation with NVIDIA quadro (FX570 if I remember properly) graphics and nvidia proprietary graphic drivers. Rest of QT/KDE apps are all well usable on this machine, though.
[Automated Action] NeedInfo-To-Unconfirmed
Created attachment 156621 [details] Video with problem
I have attached a video with the problem. It may seem a minor lag, but using LibO for long times, particularly on slides or drawings that make you use the contextual menu intensively, it is a real nuisance. I hope that the video can be enough to confirm the bug (which I now see as being unconfirmed). Screen card on which I see the problem is indeed an NVIDIA QUADRO FX 570 (G84GL). This is now an older card (circa 2010, I think), but was once a strong card with dedicated RAM and it is still a decent performer with day to day work. The weird aspect is that playing with the LibO contextual menu (as in the video) causes the GPU utilization to jump to 25-30% (from the nvidia control panel) and the CPU utilization to 100%, which seems a bit too much for a little menu. Using the GTK3 VCL there is no issue (contextual menu is snappy and cpu use stays at < 4% for the LibO process). If the issue cannot be fixed, I really think that LibO would better default to gtk3 even on KDE at least on older hardware (using a blacklist as for opengl?)
(In reply to sergio.callegari from comment #10) > ... > If the issue cannot be fixed, I really think that LibO would better default > to gtk3 even on KDE at least on older hardware (using a blacklist as for > opengl?) Waiting back a fix for KDE, you can launch a term/console and type: export SAL_USE_VCLPLUGIN=gen && soffice or export SAL_USE_VCLPLUGIN=gtk3 && soffice You can also make an alias so it's not too long to type.
Indeed, the alias with SAL_USE_VCLPLUGIN=gtk3 is what I have now. For some reason, "gen" gives me very small fonts on this system (probably, because it expects the screen DPI to be detectable in a different way).
(In reply to sergio.callegari from comment #10) > I hope that the video can be enough to confirm the bug (which I now see as > being unconfirmed). Thanks for the video, let's set to NEW, s.a. comment 4 that gives a potential explanation for the behaviour.
Just noticed that on more modern hardware (tried on haswell) you can see the issue by looking at cpu usage. If you open the contextual menu and rapidly move the mouse cursor up and down, so that the blue highlight has to follow the mouse over the contextual menu entries, the cpu usage rises sharply. With regular menus this does not happens. I think that this completely confirms the explanation in comment 4.
I plan to take a look, probably next week. Implementing native context menus for qt5 VCL should hopefully fix this one, and bug 130341 as well.
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1e0b16f8695498e4eea7c2208aabf7e7664ce749 tdf#128921 tdf#130341 tdf#122053 qt5: Native PopupMenus It will be available in 7.0.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
This should be fixed on master now, backport for 6.4 pending in Gerrit: https://gerrit.libreoffice.org/c/core/+/88491 @Sergio: The context menu is a bit faster here now, but since I couldn't really reproduce, please leave a comment here if this does not solve the slowness for you.
Michael Weghorn committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/ceb2f69e0ef2381ce6ed8c65ea45e72aa86cda56 tdf#128921 tdf#130341 tdf#122053 qt5: Native PopupMenus It will be available in 6.4.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.