[Libreoffice-bugs] [Bug 105575] Slow rendering when using a Logo command

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=105575

--- Comment #13 from Jan-Marek Glogowski <glogow at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20210806/37474617/attachment.htm>