Bug 33315 - RC4 Toolbars issue -- similar to 33088?
Summary: RC4 Toolbars issue -- similar to 33088?
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
(earliest affected)
3.3.1 RC1
Hardware: Other Windows (All)
: medium normal
Assignee: Don't use this account, use tml@iki.fi
Depends on:
Reported: 2011-01-20 18:16 UTC by Steven W
Modified: 2011-02-20 13:13 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:
Regression By:


Note You need to log in before you can comment on or make changes to this bug.
Description Steven W 2011-01-20 18:16:17 UTC
When I'm running my mouse over any of the toolbars in various components (Writer, Calc, Draw) I can hear the fan in my computer kick up a notch.  I also note that while the response after clicking these are not slow like the menus were in bug 33088, the drop-down arrow (on items that have one) will vanish momentarily, like the wording did in that bug. While not as severe, I'm hoping that someone will look and hopefully find a bottle-neck like Mr. Lillqvist discovered for 33088.

FYI, I'm running XP on a Pentium 4 installation is on the hard drive.
Comment 1 Steven W 2011-01-20 19:32:20 UTC
Compared to OOo tooltips (mouse-over text) don't take quite as long to appear.
Comment 2 Noel Power 2011-01-21 02:54:09 UTC
tor, can you have a look please
Comment 3 Don't use this account, use tml@iki.fi 2011-01-21 03:01:08 UTC
Sure, we know that also in the toolbar code is a similar pointless call to GetHelpText(). But by the time the menu problem slowness showed up (only in 3.3.0 rc3, for some reason) and was reported, we were in absolute minimal-changes-only mode for 3.3.0, so just the even more apparent slowness in menus was fixed. But for 3.3.1 we will fix it also for the toolbars, sure.
Comment 4 Don't use this account, use tml@iki.fi 2011-01-21 03:34:46 UTC
Suggested patch, one approval needed for commit to the libreoffice-3-3 branch.

commit bd7abc67d5c4dda7506c4a4198c9bc05ae1a1791
Author: Tor Lillqvist <tlillqvist@novell.com>
Date:   Fri Jan 21 13:31:46 2011 +0200

    Avoid a pointless GetHelpText() call in the toolbox, too
    GetHelpText() can be quite heavy, see fdo#33088. Also here the return
    value is passed to ShowHelpStatusText() which doesn't do anything at

diff --git a/vcl/source/window/toolbox2.cxx b/vcl/source/window/toolbox2.cxx
index d101122..29ef64c 100644
--- a/vcl/source/window/toolbox2.cxx
+++ b/vcl/source/window/toolbox2.cxx
@@ -521,13 +521,6 @@ void ToolBox::Highlight()
     ImplCallEventListeners( VCLEVENT_TOOLBOX_HIGHLIGHT );
     maHighlightHdl.Call( this );
-    XubString aStr = GetHelpText( mnCurItemId );
-    if ( aStr.Len() || mbHideStatusText )
-    {
-        GetpApp()->ShowHelpStatusText( aStr );
-        mbHideStatusText = TRUE;
-    }
 // -----------------------------------------------------------------------
Comment 5 Caolán McNamara 2011-01-21 03:38:36 UTC
Sure, looks good, but can we remove all uses of "mbHideStatusText" and remove the empty ShowHelpStatusText and HideHelpStatusText calls as well.
Comment 6 Don't use this account, use tml@iki.fi 2011-01-21 03:52:18 UTC
(13:41:45) tml_: caolan: sure, but that would be for master; for 3.3 I was wondering whether even just removing those lines was too much, and should I have just made the aStr string empty;)
(13:42:06) tml_: one can't be too paranoid;)
(13:43:56) caolan: *shrug*, IMO you're on safer ground in removing Hide|Show StatusText and making the logical changes that flow from that. Either way is fine by me for 3-3

Pushed to 3-3 branch. Will presumably get merged into master, but there I think I will do what Caolán suggested.
Comment 7 Steven W 2011-02-13 19:29:21 UTC
Hello all, I'm re-opening this bug.  The behavior is improved in that I don't see the drop-down arrows disappearing, but something is still wrong.  Under normal usage, I can here my CPU fan kick up now and then.  I have discovered that if I take my mouse and run it along the items on the toolbar(s), the CPU usage gets a little high.  Below are links to two videos that demonstrate this.

This one shows OpenOffice.org 3.3.0:


(note the CPU usage stays relatively low 06 in Windows Task Manager)

This one shows LibreOffice 3.3.1 RC1:


(CPU usage goes up to 43 in the Task Manager)
Comment 8 Steven W 2011-02-20 13:13:27 UTC
I've decided to close this and file a new bug as I believe the issues are likely separate.