`accessibility` feature have big performance impact on big listview

[qarmin]

Slint 1.3.0 - 2acaa22

Steps to reproduce

git clone https://github.com/qarmin/czkawka.git
cd czkawka
git checkout 727dd4fce805205052ae4238daacbada15b5e7f1
cargo run --bin krokiet # should run build without accesskit
# Uncomment here line in Cargo.toml about accessibility
cargo run --bin krokiet

running app with accessible feature

simplescreenrecorder-2023-11-06_21.41.30.mp4

I was able to found that this was caused by enabling accessible feature, because i_slint_backnd_winit::accesskit took most of the time of running app

Running app without feature

simplescreenrecorder-2023-11-06_21.38.37.mp4

Not sure if this problem is fixable, so if it can't be fixed, there should be a mention in the documentation about possible performance problems in certain situations

[tronical]

Thanks for reporting this. As always, looks absolutely legit and thanks for the detail.

Two things stick out for me.

1. the tree updates seems slow. Perhaps something can be done here to make them lazier for list views.
2. Let me guess: you don’t have a screen reader or any other assistive tech running? Then you should not have to pay any performance price (apart from the accessibility bus launch). However I think this part may not be implemented in AccessKit.

The overview at https://www.freedesktop.org/wiki/Accessibility/AT-SPI2/ says that apps should look for the a11y status property. I can see how other toolkits check for that, but I can’t find that logic in AccessKit. It looks to me that if the bus is present (which it always is since auto-started), then it will send updates. I may be overlooking something though.

(I know on macOS AccessKit only kicks in when requested by the OS)

[qarmin]

I used this feature because it already is available by default in Cargo.toml (

slint/api/rs/slint/Cargo.toml

Lines 23 to 31 in 2acaa22

	default = [
	"std",
	"backend-winit",
	"renderer-femtovg",
	"renderer-software",
	"backend-qt",
	"accessibility",
	"compat-1-2",
	]

) and I didn't saw a reason why I should disable it(but now I see and I disabled it immediately).

I don't have any hardware or software that could use this feature at this moment

[tronical]

Thanks. I've filed AccessKit/accesskit#314 to discuss this with the accesskit folks.

[bjorn]

I'm also experiencing this performance issue on Linux / Xfce / winit (any renderer).

Thanks. I've filed AccessKit/accesskit#314 to discuss this with the accesskit folks.

I think this is only tangentially related, since the performance issue we're seeing is severe enough that also those relying on the accessibility feature would be bothered by this. It feels to me like there's something really going wrong. Possibly some combination of:

• Rebuilding the entire accessibility tree, rather than doing incremental updates.

• Queuing up said rebuilds while handling scrolling events, causing many rebuilds to happen of which the majority are already outdated from the start (just guessing here, but it has the performance characteristics of such behavior).

[tronical]

So this won't hit anymore by default after #4261 . I'll leave this open as suggested by @bjorn as there are probably ways to speed up the tree updates. In practice I'm not sure this is an issue though. Smooth scrolling might not be needed when using assistive tech.

[mwcampbell]

Users of assistive tech other than screen readers, such as screen magnifiers or alternative input methods, are likely to care about this issue. Can someone who's good at using a profiler, on a platform where there's a profiler that works well with Rust, look into this?

[mwcampbell]

Can someone please provide instructions to reproduce the problem, or a stand-alone example of a list view with enough items in it? The demo videos aren't useful to @DataTriny and me, the main developers of AccessKit; we're both visually impaired ourselves. Thanks.

[mwcampbell]

Can someone still reproduce this performance problem with the latest version of slint? Note that it would have to be done with a screen reader or other assistive technology running if using Windows or macOS, or with the IsEnabled property of org.a11y.Status set to true on a free desktop. I'm now aware that an effect of lazy initialization, which AccessKit now does across all three platforms, is to sweep performance problems like this one under the rug, until an assistive technology user discovers them.

Since this is the one real performance problem I've heard of that's definitely AccessKit-related, I'd like to dig into it.

[DataTriny]

This issue is on my watch. I plan to check it back once a couple of more fundamental issues with list views are solved. But since Slint now only include the visible items in the accessibility tree, I am pretty confident that the performance cost does not grow with the number of items.