Michael Meeks

Hmm - I strongly suspect the memory blow-out and swapping which matches that profile and the very significant memory use can only come from that. I imagine that it is...

I suspect we should break out the performance problems here that can't be seen in the profile into their own tickets: * full-sheet invalidations left & right - it looked...

We should really look at that view switching cost: doc_setView should be the moral equivalent of a single pointer change it's strobed at very high frequency =) Instead in this...

Interesting: the mouse event processing seems to have an un-wanted inferior main-loop from chart::ChartControlller::executeDlg_ObjectProperties_withoutUndoGuard - which needs to be async'd:  And of course the amount of work done in...

@grandinj This ticket is probably interesting for you with its weekly feed of profiling porn :-)

I think it seemed slow to scroll down slides on the mobile device; -but- we were in readonly mode - and we could have significantly increased the window of slide-thumbnails...

Looks to me like we've got some galloping invalidation problem that is causing lots of tiles to be rendered un-necessarily. I would expect to see the event handling, spell-checking, editing...

Hmm; I'm surprised to see the DrawBitmapEx doing that slowish clip/composite path; is there some rotation or other going on there? trace is a bit odd too, might be nice...

Hopefully the ~8%+ of doc_setView cost is gone in 24.04 with the fix there (?)

~18% of the time in GetWaterMark is indeed interesting; and it seems there is far too much invalidation & re-layout going on playing with the document.