Bug Hunting Session
Bug 33088 - Menu rendering problems?
Summary: Menu rendering problems?
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
3.3.0 RC3
Hardware: Other Windows (All)
: medium normal
Assignee: Don't use this account, use tml@iki.fi
URL:
Whiteboard:
Keywords:
: 33134 (view as bug list)
Depends on:
Blocks: 31865
  Show dependency treegraph
 
Reported: 2011-01-13 23:19 UTC by Steven W
Modified: 2012-04-05 09:01 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Steven W 2011-01-13 23:19:56 UTC
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.
Comment 1 Steven W 2011-01-13 23:51:11 UTC
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
Comment 2 vitriol 2011-01-14 02:00:37 UTC
Same problem under Windows Vista. The main menu responds very slowly, and the menu items flicker at the mouse passing.
Comment 3 Don't use this account, use tml@iki.fi 2011-01-14 07:41:50 UTC
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).
Comment 4 Steven W 2011-01-14 08:52:30 UTC
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.
Comment 5 Steven W 2011-01-14 09:02:25 UTC
Chnaging 'Version' to RC3, as it is now one of the choices.
Comment 6 starmatz71 2011-01-14 15:05:09 UTC
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.
Comment 7 grigoreflorin1985 2011-01-14 15:33:26 UTC
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.
Comment 8 Steven W 2011-01-14 20:27:10 UTC
You're right, florian, RC2 does not display this particular behavior.  The Standard Menu behaves comparably to OOo.
Comment 9 Steven W 2011-01-14 20:28:24 UTC
(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!
Comment 10 Don't use this account, use tml@iki.fi 2011-01-17 02:50:54 UTC
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.)
Comment 11 Michael Meeks 2011-01-17 03:01:17 UTC
*** Bug 33134 has been marked as a duplicate of this bug. ***
Comment 12 Michael Meeks 2011-01-17 03:02:44 UTC
making a 3.3.0 release blocker - thanks guys.
Comment 13 Don't use this account, use tml@iki.fi 2011-01-17 03:03:07 UTC
I don't notice the menu entry blinks in OOo 3.3 RC9. So this seems to indeed be a LibreOffice-only problem.
Comment 14 Don't use this account, use tml@iki.fi 2011-01-17 03:40:14 UTC
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.
Comment 15 grigoreflorin1985 2011-01-17 03:54:06 UTC
(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
Comment 16 Don't use this account, use tml@iki.fi 2011-01-17 07:04:50 UTC
"easy to fix", eh? Did you have a look at bug #31716 and did you notice how hard that was to fix?
Comment 17 Michael Meeks 2011-01-18 02:40:08 UTC
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.
Comment 18 Don't use this account, use tml@iki.fi 2011-01-18 02:45:51 UTC
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 .
Comment 19 Don't use this account, use tml@iki.fi 2011-01-18 02:54:18 UTC
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++
Comment 20 Don't use this account, use tml@iki.fi 2011-01-18 02:58:56 UTC
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.
Comment 21 grigoreflorin1985 2011-01-18 03:08:51 UTC
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.
Comment 22 Don't use this account, use tml@iki.fi 2011-01-18 03:19:54 UTC
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.
Comment 23 Don't use this account, use tml@iki.fi 2011-01-18 04:13:57 UTC
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.
Comment 24 Don't use this account, use tml@iki.fi 2011-01-18 04:24:32 UTC
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.
Comment 25 Don't use this account, use tml@iki.fi 2011-01-18 06:50:03 UTC
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
Comment 26 Steven W 2011-01-18 15:31:29 UTC
(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.
Comment 27 Not Assigned 2012-04-04 12:02:34 UTC Comment hidden (off-topic, wrong-bug-id)
Comment 28 Eike Rathke 2012-04-04 12:08:28 UTC
(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.
Comment 29 Rainer Bielefeld Retired 2012-04-05 07:51:38 UTC
I added Fix submitter as assignee because this will ease queries and bug tracking.
Comment 30 Eike Rathke 2012-04-05 09:01:21 UTC
Well, that's Tor then and not me.. see comment #28