When using any component, Writer, Draw, Calc, etc., and placing the mouse over anything in the Standard Menu -- File, Edit, etc., the word that you're mousing over vanishes for a fraction of a second and then reappears. This also occurs in the menus that drop down from anything on the Standard Menu. I've seen videos on Youtube of folks using Linux distros running LibO and from the looks of it, this does not affect them; although I can't be sure. I've tried increasing memory under Tools -- Options to no avail. BTW, I'm using RC3. RC3 has not been added to Version on this site.
Well, items with a keyboard shortcut listed don't do this, but the shortcut does! Here's a video about what I mean. Notice most things disappear, but watch when I click File -- Open, the word Open doesn't disappear, but Ctrl+O does! http://www.youtube.com/watch?v=MGbz5GJDsAc
Same problem under Windows Vista. The main menu responds very slowly, and the menu items flicker at the mouse passing.
Interesting. I don't see it as severly myself, but now that I look closely, I do notice that the shortcut mentioned for some menu entries clearly is removed for a short while when I mouse over it and it is highlighted. This is more noticeable with the longer shortcuts, like Ctrl+Shift+S for File:Save As. I don't see any blinking of the menu entries themselves, though. This is on Windows Server 2008 R2 (i.e., Windows 7 server version).
Maybe I should mention I'm on XP and have a P4 3 GHz. I would say that the whole program is a bit slow compared to OOo, but I wouldn't say "very slow". I've noticed that there's been some speed improvement since RC2.
Chnaging 'Version' to RC3, as it is now one of the choices.
I'am affected with this extremly slow menu behavior on an Intel Atom with 1GB RAM. I think this "bug" is a showstopper - in OOo 3.2.1 menus are fast without any noticable delay.
Hei! Download RC2 frome here http://download.documentfoundation.org/libreoffice/old/testing/3.3.0-rc2/win/x86/ and report if this bug happens in 3.3.0-rc2. On my Vista machine in RC2 no bug , in RC3 bug.
You're right, florian, RC2 does not display this particular behavior. The Standard Menu behaves comparably to OOo.
(In reply to comment #8) > You're right, florian, RC2 does not display this particular behavior. The > Standard Menu behaves comparably to OOo. Sorry, don't know why I called you florian, grigore!
In a virtual single-processor machine running XP with rc3, I do see the blinking of all menu entries. (But as I said, not on my physical (quad-core) machine running WS2008R2. So probably the machine performance indeed affects how noticeable the problem is.)
*** Bug 33134 has been marked as a duplicate of this bug. ***
making a 3.3.0 release blocker - thanks guys.
I don't notice the menu entry blinks in OOo 3.3 RC9. So this seems to indeed be a LibreOffice-only problem.
Seems to be some similar problem as bug #31716 . Using Process Monitor, I again see an awful lot of file and directory access going on in the share\extensions\presenter-screen\help directory tree while mousing over a menu. I.e. iteration over all help languages over and over again. It is quite possible that OOo 3.3 does have the same root bug, but that it doesn't cause such a visible effect for them as they don't build with multiple languages.
(In reply to comment #9) > (In reply to comment #8) > > You're right, florian, RC2 does not display this particular behavior. The > > Standard Menu behaves comparably to OOo. > Sorry, don't know why I called you florian, grigore! It is the same name but in a different language :) People it is an UI behavior and only UI , was fixed ONCE but looks that someone forgot about this one in WIN32 so this time we hope will not do the same for next releases, it is a menu draw lag and does not do any hdd behavior on files it is only menus that lag in draw. It looks that there are no menu`s but they are and apear after 1 second of redraw , from programming part fixing it means reverting to the RC2 behavior on menu drawing or something like that. Good news it is that it is easy to fix , bad news, it is that we must wait for the next release :D
"easy to fix", eh? Did you have a look at bug #31716 and did you notice how hard that was to fix?
Something similar can be reproduced under Linux - at least, the strace shows a lot of 'access' calls to help files while we mouseover the menus; we get one access call per menu item sent to: access("/usr/share/libreoffice/basis-link/help/en", F_OK) = -1 ENOENT it is unclear how that can cause a huge performance hit on windows - but; perhaps if remote file-systems are in-use or somesuch, it could be a real problem I guess. I presume that there is some confusion between "help not there" and "not checked to see if help is there" that could perhaps be resolved - digging. Steven - where is your LibreOffice installed ? on some sort of slow network drive ? - my XP shows no really noticeable delay for the menus.
You see only one seemingly pointless file access per menu item moused over on Linux? Do you have any extensions with help in multiple languages installed (look for share/extensions/presenter-screen/help/* for instance)? It's not just a single file/directory access (or just a couple) that slows it down on Windows, and no, no remote file systems need to be involved for it to be seen. It does lots and lots of lookups of files and directories related to help. See https://bugs.freedesktop.org/show_bug.cgi?id=31716#c24 .
OK, so here is a backtrace from one of the problematic code paths that slow down the menus: > ucpchelp1.dll!chelp::Content::Content(const com::sun::star::uno::Reference<com::sun::star::lang::XMultiServiceFactory> & rxSMgr={...}, ucbhelper::ContentProviderImplHelper * pProvider=0x0eee03d0, const com::sun::star::uno::Reference<com::sun::star::ucb::XContentIdentifier> & Identifier={...}, chelp::Databases * pDatabases=0x0d7b3008) Line 82 C++ ucpchelp1.dll!chelp::ContentProvider::queryContent(const com::sun::star::uno::Reference<com::sun::star::ucb::XContentIdentifier> & xCanonicId={...}) Line 221 + 0x3b bytes C++ ucb1.dll!089a045a() [Frames below may be incorrect and/or missing, no symbols loaded for ucb1.dll] ucbhelper4MSC.dll!ucbhelper::getContent(const ucbhelper::ContentBroker & rBroker={...}, const com::sun::star::uno::Reference<com::sun::star::ucb::XContentIdentifier> & xId={...}, bool bThrow=true) Line 344 + 0x1c bytes C++ ucbhelper4MSC.dll!ucbhelper::Content::Content(const rtl::OUString & rURL={...}, const com::sun::star::uno::Reference<com::sun::star::ucb::XCommandEnvironment> & rEnv={...}) Line 402 + 0x13 bytes C++ sfxmi.dll!GetHelpAnchor_Impl(const String & _rURL={...}, String & _rAnchor={...}) Line 188 + 0x8d bytes C++ sfxmi.dll!SfxHelp::CreateHelpURL_Impl(const String & aCommandURL={...}, const String & rModuleName={...}) Line 684 + 0xd bytes C++ sfxmi.dll!SfxHelp::CreateHelpURL(const String & aCommandURL={...}, const String & rModuleName={...}) Line 976 + 0x14 bytes C++ sfxmi.dll!SfxHelp_Impl::GetHelpText(const rtl::OUString & aCommandURL={...}, const String & rModule={...}) Line 371 + 0x25 bytes C++ sfxmi.dll!SfxHelp::GetHelpText(const String & aCommandURL={...}, const Window * __formal=0x00000000) Line 948 + 0x28 bytes C++ vclmi.dll!Menu::ImplGetHelpText(unsigned short nItemId=0x0001) Line 2049 + 0x1a bytes C++ vclmi.dll!Menu::GetHelpText(unsigned short nItemId=0x0001) Line 2065 C++ vclmi.dll!Menu::Highlight() Line 1124 + 0x1c bytes C++ vclmi.dll!Menu::ImplCallHighlight(unsigned short nHighlightedItem=0x0000) Line 2895 C++ vclmi.dll!MenuBarWindow::ChangeHighlightItem(unsigned short n=0x0000, unsigned char bSelectEntry='', unsigned char bAllowRestoreFocus='', unsigned char bDefaultToDocument='') Line 5519 C++ vclmi.dll!MenuBarWindow::ImplHandleKeyEvent(const KeyEvent & rKEvent={...}, unsigned char bFromMenu=0x00) Line 5790 C++ vclmi.dll!MenuBar::ImplHandleKeyEvent(const KeyEvent & rKEvent={...}, unsigned char bFromMenu=0x00) Line 3357 + 0x11 bytes C++ vclmi.dll!SystemWindow::Notify() + 0x65 bytes C++ vclmi.dll!Window::Notify(NotifyEvent & rNEvt={...}) Line 5360 + 0x2b bytes C++ vclmi.dll!Window::Notify(NotifyEvent & rNEvt={...}) Line 5360 + 0x2b bytes C++ sfxmi.dll!SfxFrameWindow_Impl::Notify() + 0x189 bytes C++ vclmi.dll!Window::Notify(NotifyEvent & rNEvt={...}) Line 5360 + 0x2b bytes C++ vclmi.dll!Window::Notify(NotifyEvent & rNEvt={...}) Line 5360 + 0x2b bytes C++ vclmi.dll!Window::Notify(NotifyEvent & rNEvt={...}) Line 5360 + 0x2b bytes C++ vclmi.dll!Window::KeyInput(const KeyEvent & rKEvt={...}) Line 4848 + 0x11 bytes C++
But note that I have no idea why this shows up in RC3 but not in RC2... As far as I could see there has been no code changes related to help text between RC2 and RC3. But there must be some obscure mechanism that causes more iteration over different language help databases (or whatever it is that the code is doing) in RC3.
I have installed libreoffice RC2 on fresh Vista32 on my Core2 1.6 ghz TabletPC menus are drawn fast like native IE or YahooMessenger/Firefox , installed RC3 and it is slow from starting up to the menus and overall performance it is down. Oposite RC2 no performance degradation from sart to menus to anoter wrier or draw. Reinstalled Vista32 clean back from backups.
Please let's not misuse this bug for vague complaints about general slowness, as in the previous comment "it is slow from starting up to the menus and overall performance it is down"... There is little reason to believe that everything in LibreOffice RC3 would be much slower than in RC2. Placebo effects can be very real. If you have come to the opinion already that RC3 is slower in all ways than RC2, that something "simple" was "forgotten" in RC3, that is also what you will see. Of course, if you can provide actual measurements done in an objective and comparable fashion for RC2 and RC3, you have more credibility.
The cause to the menu slowness seems to be this function in vcl/source/window/menu.cxx: void Menu::Highlight() { ImplMenuDelData aDelData( this ); Menu* pStartMenu = ImplGetStartMenu(); if ( !aHighlightHdl.Call( this ) && !aDelData.isDeleted() ) { if ( pStartMenu && ( pStartMenu != this ) ) pStartMenu->aHighlightHdl.Call( this ); } if ( !aDelData.isDeleted() && GetCurItemId() ) GetpApp()->ShowHelpStatusText( GetHelpText( GetCurItemId() ) ); } It's the call to GetHelpText() there that cause the heavy iteration over extension help directories in all languages. What's especially amusing is that the ShowHelpStatusText() method being called is: void Application::ShowHelpStatusText( const XubString& ) { } (Sure, Application::ShowHelpStatusText() is virtual, but that is the only implementation of it, if one can trust OpenGrok, and indeed in this case the one that is called.) So an obvious fix would be to delete the two lines: if ( !aDelData.isDeleted() && GetCurItemId() ) GetpApp()->ShowHelpStatusText( GetHelpText( GetCurItemId() ) ); and indeed, that helps. Running Process Monitor, I see that with the original code, just opening the File menu and moving one step down, causes thousands of file and directory access "system calls" to be made. Removing those two lines, none at all. Now, of course it is remotely possible that the call to GetHelpText() here has some intended side-effect, but I very much doubt it. Also, it is of course possible that some day ShowHelpStatusText() will actually do something, or that GetApp() will in some case return a subclass of Application that has an implementation of ShowHelpStatusText() that actually does something. So, I would think that for 3.3 and 3.3.1 we should just delete those two lines. But in master we should add a new virtual method to Application: virtual bool DoesShowHelpStatusTextDoAnything(), which by default then returns false, and then call that to decide whether to call ShowHelpStatusText() or not.
Or actually, in master we should fix the compiled-help code to not do the same stuff over and over again, but use more intelligent caching of information already once found out. Unfortunately that might be a bit hard.
Fixed now in libreoffice-3-3 and libreoffice-3-3-0 branches: commit 6fc21aa74b4d2aba07d854d5d3c2f404905b40ef Author: Tor Lillqvist <tlillqvist@novell.com> Date: Tue Jan 18 16:25:52 2011 +0200 Avoid GetHelpText() call which can be quite heavy GetHelpText() can cause a quite heavy sequence of file and directory lookups. See fdo#33088. As its return value here was just passed on to ShowHelpStatusText() which doesn't do anything at all, it was completely unnecessary. The GetHelpText() calls here caused the noticeable slowdown in highlighting menu items on Windows with lots of localised help files for some bundled extensions. Signed-off-by: Caolan McNamara <caolanm@redhat.com> Signed-off-by: Michael Meeks <michael.meeks@novell.com> Signed-off-by: Thorsten Behrens <thb@documentfoundation.org> Signed-off-by: fstrba@novell.com
(In reply to comment #17) > Something similar can be reproduced under Linux - at least, the strace shows a > lot of 'access' calls to help files while we mouseover the menus; we get one > access call per menu item sent to: > > access("/usr/share/libreoffice/basis-link/help/en", F_OK) = -1 ENOENT > > it is unclear how that can cause a huge performance hit on windows - but; > perhaps if remote file-systems are in-use or somesuch, it could be a real > problem I guess. I presume that there is some confusion between "help not > there" and "not checked to see if help is there" that could perhaps be resolved > - digging. Steven - where is your LibreOffice installed ? on some sort of slow > network drive ? - my XP shows no really noticeable delay for the menus. Michael, My installation resides on the hard drive. Other than the connection to my cable modem (internet), this computer is not networked.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=58e562e730485e860dfe484cdc09c67f1d73dc5a fdo#33088 better CSV import default separators
(In reply to comment #27) > Eike Rathke committed a patch related to this issue. No, he didn't, that was a typo and meant for bug 38088 instead.
I added Fix submitter as assignee because this will ease queries and bug tracking.
Well, that's Tor then and not me.. see comment #28