In the Sidebar, if it is currently on Properties and you click on Styles and Formatting in the TabBar then there is a delay before it displays. 1. New Text Document. 2. Open Sidebar, if it is not currently displaying Styles and Formatting then click on it. Expected: No delay. Result: Delay of 2 to 3 seconds. 1. New Text Document. 2. Insert Table 2 x2. 3. Open Sidebar to Styles and Formatting. 4. Place cursor outside of table. 5. Place cursor inside table. Result: Styles and Formatting flickers for a few seconds before landing on the current style. Open any document with lots of different styles and move the cursor about in the document with Styles and Formatting open. There is a delay until it settles upon the current style. This might not be related but I was seeing 25% cpu usage with the following document, but it was happening even with the Sidebar closed. https://wiki.documentfoundation.org/images/2/2f/WG42-WriterGuideLO.odt Windows Vista 64 Version: 5.0.0.0.alpha1+ Build ID: 60fb87cf6cfcbdb1a7ece00e8a2e9d1112903ed0 TinderBox: Win-x86@39, Branch:master, Time: 2015-05-18_14:12:34
Reproduced both issues. Win 7 Pro 64-bit Version: 5.0.0.0.alpha1+ Build ID: 158b50763962f66515062300e265839828463efa TinderBox: Win-x86@39, Branch:master, Time: 2015-05-19_00:28:31 Locale: fi-FI (fi_FI)
Is this in a release build, or a dbgutil build ? =) dbgutil is of course doing a lot more checking of this & that which may affect things.
I downloaded it from http://dev-builds.libreoffice.org/daily/master/Win-x86@39/ Is beta built the same way and is it configured for parallel install?
(In reply to Michael Meeks from comment #2) > Is this in a release build, or a dbgutil build ? =) dbgutil is of course > doing a lot more checking of this & that which may affect things. No dbgutil found here in the arguments for TB 39: http://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTER&full-log=1432225802.9609
Created attachment 115840 [details] profile of switching a few times ...
*** Bug 91460 has been marked as a duplicate of this bug. ***
This is nothing to do with VclPtr; or with the RenderContext work (AFAICS) - it's down to the new style preview work in master. The profile shows that we do some horrendous N^2 cost here; we do: 2440 - calls to CreateStylePreviewRenderer - which takes 13bn pcycles with just default styles; (though this is in an unhelpful dbgutil build). I've a small patch that shaves some of them off; but it's a pointless micro-optimization. If we do something like this: --- a/svx/source/styles/CommonStyleManager.cxx +++ b/svx/source/styles/CommonStyleManager.cxx @@ -22,17 +22,33 @@ sfx2::StylePreviewRenderer* CommonStyleManager::CreateStylePreviewRenderer( if (!pPool) return nullptr; + SfxStyleSheetBase *pFindStyle = pPool->Find( rName, eFamily ); + if (pFindStyle && getenv ("FOO")) { + SAL_DEBUG("hit"); + return new CommonStylePreviewRenderer(mrShell, rOutputDev, pFindStyle, nMaxHeight); + } + pPool->SetSearchMask(eFamily, SFXSTYLEBIT_ALL); SfxStyleSheetBase* pStyle = nullptr; Life gets faster, but goes wrong too. It seems that looks up by UI names and not programmating style names; ie. we see an rName of '"Default Style" -> UI Name and not 'standard' - which is annoying. The Find() appears to (nearly) work and is a lot faster but gets the font weights wrong (interestingly) - so we need to iterate and pStyle->GetName() comparison.
Tomaz - we should fix this before 5.0 I guess; it takes me ~3 seconds to switch to the previewed style stuff =) It seems (to me) that the infrastructure is pretty screwed up there - and we need a way to cache this in some hash - but then we need to be able to invalidate that in some sensible way (I guess). Ho hum ... =)
Michael Meeks committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5122f3c5459d9b4053485241292728cd770cbaf8 tdf#91368 - micro-optimization for over-used method. It will be available in 5.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Hi WORKSFORME on Windows 7/64 & Version: 5.2.0.0.alpha1 (x64) Build ID: 902b28a39528b6c92602e9b521a1d0861be1caf9 Threads CPU : 2; Version de l'OS :Windows 6.1; UI Render : par défaut; Locale : fr-FR (fr_FR) Thank you Regards