StandardTableView causes the CPU to occupy 100%, and then the UI freezes

[vonnieda]

Discussed in #3601

Please see comment for full details and a short test case.

In short, when scrolling the StandardTableView quickly, there are huge spikes in CPU and the frame rate drops to 0. This is happening even in a simple table with 100 rows of 6 text columns, which is demonstrated in the attached app. If you bump it up to 1000 rows you start getting complete UI lockups with Mac beach balls, and 10k rows is unusable.

[vonnieda]

Video to show the issue attached:

Screen.Recording.2024-04-11.at.4.44.43.PM.mov

[vonnieda]

I've confirmed (after simon asked on Mattermost) that this is a regression that happened between 1.4.1 and 1.5.0, and also exists on 1.5.1.

This can be seen in the test case posted at https://github.com/slint-ui/slint/files/14938821/my-project.zip by changing the slint dependency to "= 1.4.1" or "= 1.5.0", and changing the row count to 1000.

In 1.4.1 using the mouse wheel to scroll the list (or dragging the thumb) is smooth. In 1.5.0+ there are big jumps in lag, beachball timeouts, FPS = 0, etc.

Discussed with simon here: https://chat.slint.dev/public/pl/a8jn76pua3nr8xdbq8q49dasww

[ogoffart]

I could reproduce the problem with the winit backend (not with the qt backend)

Profiling shows that all the CPU is spend in accessibility handling (despite I don't have a screen reader setup)

Workaround: Disable the accessibility feature of Slint.

[ogoffart]

This should normally be addressed with the port to winit 0.30 in the master branch

[tronical]

I can confirm that commit dc9f1d5 fixed this via the pending_update mechanism. I tried the example in #5338 and while in 1.6 it stalled after resizing, in 1.7 the spinner resumes immediately and debug output also confirms that only one timer is started and the tree is rebuilt only once.