Apache OpenOffice (AOO) Bugzilla – Issue 106100
Slow reaction on rightclick in writer and impress
Last modified: 2013-08-07 14:44:00 UTC
Using the contextmenu(rightclick without selection of text) in writer or impress takes up to 3 seconds on slow maschines (e.g. intel atom netbook). On faster PCs it is better, but the contextmenue dosent appear immediately. During the test we discovered: After opening and closing the menue TOOLS-EXTENSION the rightclick brings the contextmenue as fast as it should be!? This works till closing openoffice incl. systray (Faststart) and starting openoffice again. We tested the 2 different situation with filemon(WinXp) and processmon (Win 7) When the reaction is slow(3s) we recorded about 28000 fileevents - after opening and closing TOOLS-EXTENSION we recorded only 4000 fileevents! We reproduced the problem on several machines (Core2Duo, Intel Atom, P4) with different OS-Types (WinXPpro Sp1, SP3 and Win7pro Final) and different versions of OpenOffice (3.1.1 and dev300m60) with different extensions (sun report builder, dudenkorrektor 6.0, pdf-import, presenter console, several dictionaries) Please help to improve the slow reaction. Thx mhxat
I can confirm this behavior.
Thomas, please take over. It seems that some caching is needed.
.
Using log files the following was found when tracing the 2nd call when opening the menu: - overall time until the context menu gets displayed: ~485 ms - excluding all parts that are only within the resolution of the time the problem comes down to 4 calls to GetHelpText(nSlotId), each of them taking 78, 94, 94 and 94 ms, which amounts to an overall of 360 ms. The calls to this function while opening the context menu look like this: 1) SfxUnoMenuControl* SfxMenuControl::CreateControl 2) SfxVirtualMenu::CreateFromSVMenu ~ line 498 when calling Bind 3) SfxVirtualMenu::CreateFromSVMenu ~ in line 576 when calling Bind + n-times) the same as in 3) 4) SfxVirtualMenu::CreateFromSVMenu ~ line 569 when calling Bind + m-times) the same as in 4) Thus we have 4 different locations where the help text is obtained. If this is to be improved within sfx2 then it should be possible to get the help text just once and pass it down to the other functions that have need for it. However, if the extension manager was opened, the overall time to display the context menu is still somewhat smaller then what could be obtained here in sfx2 by implementing the above fix. After the extension manager was opened, the code execution up to executing the context menu is only just about 75 ms. Thus there still seems to be some other, though compared to GetHelpText, rather small beneficial effect.
Unfortunately the propose fix did not work at all. It turned out that the 4 calls to GetHelpText that are in question are calls for different slot ids and thus no time all can be saved in this way. :-(
Following the problem further down the code it turns out that the lies with GetHelpAnchor_Impl in sfx2/source/appl/sfxhelp.cxx. Here a ::ucbhelper::Content named aCnt is created an then aCnt.getPropertyValue( ... ) gets called. This call is the single root for the problem with the slow context menu. For the time being we should wait until AB is back next Monday for further discussion.
tl->ab: Please have a look. Thanks!
1 Question: Is there a way or a workaround to accelerate the contextmenue in OO 3.1.1? Maybe a startupscript - which is doing a similar action ... like opening the extensionmanager? I ask because: I stopped a rollout to prevent bad OO.org userexperience (Customers=decisionmaker). Thx mhxat
FIXED
ab->sba: Please verify For testing I used sun-connector-alfresco.oxt that caused the described problem on Offices without the fix
Verified in CWS fwk125. SBA->mhxat: Of course, opening the extension manager dialog, doing nothing and closing it again would be a workaround. This must take place at the beginning of every office session and should be possible via an auto-executing macro. Note that the macro security settings must be set accordingly, SOME people might fear this for good reason :-) Since this problem depends on "certain" extensions, you can also disable the extensions that cause this by default. If a user enables it again for his session, he will have had the extension manager dialog open and run into the other workaround.
Thx for answer. 320m7 works fine! Pilot starts with 320m7! Thanks for support!
sba -> mxhat: Thanks for the comment. OK in OOO320_m7. Closing issue.