Delay when navigating through ListView items with an assistive technology running

[DataTriny]

Bug Description

There is a noticeable delay when navigating through items in a ListView. I can't tell at this point whether this only occurs when accessibility is involved or if there is a more general issue behind.

It happens when tabbing into the ListView when no item was previously selected, when using arrow keys and other keys to move the selection and also when clicking if the ListView has the focus. Interestingly the bug does not show up when tabbing into the ListView if an item was previously selected.

Here are some logs from the NVDA screen reader with timestamps.

When using the up arrow to select and focus the first item:

IO - inputCore.InputManager.executeGesture (20:44:34.568) - winInputHook (26248):
Input: kb(desktop):upArrow
IO - speech.speech.speak (20:44:34.758) - MainThread (17736):
Speaking [LangChangeCommand ('fr_FR'), 'Emil, Hans', CancellableSpeech (still valid)]

When using Tab to move into the ListView while the first item was already selected (but not focused):

IO - inputCore.InputManager.executeGesture (20:47:37.167) - winInputHook (26248):
Input: kb(desktop):tab
IO - speech.speech.speak (20:47:37.188) - MainThread (17736):
Speaking [LangChangeCommand ('fr_FR'), 'Names', 'liste', CancellableSpeech (still valid)]
IO - speech.speech.speak (20:47:37.188) - MainThread (17736):
Speaking [LangChangeCommand ('fr_FR'), 'Emil, Hans', CancellableSpeech (still valid)]

As you can see, the nominal case takes approximately 20ms while it takes 200ms otherwise.

I first thought this could be linked to the various animations that are triggered when a ListView item gets the focus, so I modified the durations inside i-background, i-text and i-selector in the Fluent style ListItem component. Setting these to 0 or a large value didn't seem to change anything though.

Reproducible Code (if applicable)

The CRUD example exhibits the issue.

Environment Details

• Slint Version: master (since we made ListView items accessible)
• Platform/OS: Windows
• Programming Language: Rust
• Backend/Renderer: winit

Product Impact

No response

[DataTriny]

The amount of time between a key event and a tree sent to AccessKit is less than 11ms on a debug build and less than 5ms on a release build. Time was measured after calls to Adapter::update_if_active, so at this point events are already dispatched to the platform accessibility stack. Something interesting to note is that I can see a delay of 200-300ms on NVDA logs with both a debug and a release build.

The winit event loop appears to not pause after the tree update so I assume requests from assistive technologies to get fresh information about nodes are not delayed.