https://bugs.documentfoundation.org/show_bug.cgi?id=105575
--- Comment #13 from Jan-Marek Glogowski <glo...@fbihome.de> --- So this should have been just a quick look and turned into some hours analysis with multiple problems unveiled... Just for the "fun" of it, I did throw the example into callgrind. In my symbol+assert build, I found that the primary problem is dynamic_cast's strcmp from the assert in "SwContact* GetUserCall(const SdrObject* pObj)". Commenting that, and running callgrind again, I found dynamic_cast still to be a problem, but much less ;-) Now 10% of the time is spend in __gnu_cxx::__normal_iterator... SwObjectFormatter::FormatObjsAtFrame_ SwSortedObjs::ListPosOf __gnu_cxx::__normal_iterator That's one reason why the progress gets slower. The LO code iterates over the graphics objects vector to find the matching SwAnchoredObject. Normally that code is no problem, since we don't have 400 draw objects and "everytime" add a new one causing a relayout with several of these lookup. And the display was never refreshed in callrind, until LibreLogo was finished. But back to the original problem: !! 1. Make sure the document language is English !! I had my master build with en UI, but German system, resulting in an error message about braces and whitespace. I originally didn't even realize the error message was German; took me, while trying to fix the logo program ;-) master kf5 (symbols + asserts, no debug): ~40s 5.0.6.2 gtk2 (from git releases; I like that repo): ~120s to finish with several "hiccups", i.e. the turtle speed differed (different from the general slowdown already described above) master gtk3: ~150s master gen: ~4s (really; just does a single paint refresh, and I guess no intermediate layouts; not yet analyzed...) FWIW the "svx::SdrPaintView aComeBackIdle" has TaskPriority::REPAINT, but it probably should be TaskPriority::RESIZE AKA just above repaint (and maybe RESIZE should be rename PREPAINT, and REPAINT just PAINT...). It feels a bit faster, but with kf5 at 40s + manual timing... There are two main difference between Qt and the other system loops: 1. Qt can't process single events. You can just decide between "process all events" and "wait for events and then process all". And it has a bit different painting semantics, so a refresh most times get queued in the system event loop. I'm for that approach generally... 2. gtk and win process LO events via system loop. All other process them always before system events. That is nothing new, but it might interfere here and they should probably get converted to the general processing via SalUserEventList (don't ask me why it's called UserEvent...; I just introduced SalUserEventList, not SalUserEvent). This needs much more work; maybe we should just switch to GMainLoop, but that would be a mayor change for all backends again...) and we have the UI in main problem, bust that might be solvable generally with std:: And then there is the headless locking problem with UI tests too, where we don't want to run the main loop via yield "out of order", with non-releasing SolarMutex m_bNoYieldLock hack. And nothing obvious and quick to fix this. I guess at least a month to convert all VCL backends after finishing headless (which should work; it has some focus handling problem, which are hacked around by ignoring visibility...). -- You are receiving this mail because: You are the assignee for the bug.