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.
Compared to OOo tooltips (mouse-over text) don't take quite as long to appear.
tor, can you have a look please
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.
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 all. 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; - } } // -----------------------------------------------------------------------
Sure, looks good, but can we remove all uses of "mbHideStatusText" and remove the empty ShowHelpStatusText and HideHelpStatusText calls as well.
(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.
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: http://www.youtube.com/watch?v=-OqX-gGX9-8 (note the CPU usage stays relatively low 06 in Windows Task Manager) This one shows LibreOffice 3.3.1 RC1: http://www.youtube.com/watch?v=aMcs71y4aQM (CPU usage goes up to 43 in the Task Manager)
I've decided to close this and file a new bug as I believe the issues are likely separate.