perf: smoother scrolling ...

[mmeeks]

Just wondering what's up with scrolling in writer - I load our writer sample document from make run and go to the nice big purple image which gives a good view of what's up.

Then I scroll with the touch-pad up and down - it 'feels' not entirely smooth; profile here:

And I wonder ;-) but need someone clueful to comment. Is it possible that:

• touchpad has a certain typematic rate - and we get a series of 'jerks' as the display moves from the events, and we would do well to animate between them for a more fluid look.
• there are a load of overlapping 'Animation' things - is this for the 'comments' that sit on top of the writer document and seem to move (nicely) but out of sync with the document ;-)
• The CollectAutofillContentService.processMutations stuff from (I guess) this 'bootstrap' code - seems to take a surprising amount of time - I've seen some chunks of profile that have a millisecond of JS doing (who knows what) in 'processMutations' - is it possible that our attempts to touch the DOM / do changes at a co-ordinated time are somewhat stymied by this well hidden 'Idle' event processing ? would adding a forced processMutations at the end of some 'resumeDrawing()' method or "messagesdone" event be useful ?

Would be great to have a poke about to see if there's something up there; I fear we have some self-inflicted paper-cuts there that perhaps we could fix easily ;-)

[mmeeks]

Interestingly it seems like various overlays / sections are particularly expensive to update - it's also notable that the comment bubbles seem to wander wrt. their position vs. the document - might be nice to render them on the canvas itself somehow if that's possible (?)

And of course there is a chunk of low hanging waste here: that #10441 should help with the comments above.

[Cwiiis]

#10772 fixes the huge chunk of time that CommentSection is taking while scrolling (and also fixes comment scroll position lagging behind actual scroll position).

[Cwiiis]

Fixing GC (#11389), improving pre-fetching (#11496), using ImageBitmap (#11508), only drawing once per frame (landed in #11577), being smarter about destruction of resources (#11597), and probably various other fixes have made huge progress in this area. There is still more we can do, but I wonder if we need a general issue like this at this point?

I've filed #11375 about poor HRuler performance harming scrolling performance and also have plans about offloading more work to workers, using multiple workers (#11469) and allowing cancellation of tile decompression (would be useful for fast scroll-handle scrolling), but I dare say we're in a pretty reasonable state now with regards to scroll smoothness.

[DavyLandman]

I don't know if it helps, but we found that scrolling using the scrollbars instead of the mouse/touchpad made the scrolling s whole lot smoother.

[mmeeks]

@DavyLandman interesting - what version are you using ? =) huge changes here in 25.04.

[DavyLandman]

aha, I'm on: collabora/code:24.04.13.3.1 so yeah, I'll update that as soon as I can. I'll report back after that.

wait @mmeeks that's not released yet. is there a place I can pickup an docker image and try it?

[DavyLandman]

@mmeeks I can confirm that 25.04 indeed has a lot smoother scroll 👍🏼 great work.

[mmeeks]

Nice of course 25.04 is somewhat rough and we're working on it hard, but glad to hear your scrolling is smooth :-) the profiles suggest it's mostly doing what it should be now which is good.

Large view jumps need better pre-loading and so on but ... lets see :-)