@feerrenrut here also, even more than for #10307, the retrieval of the filtered items is much slower than their drawing.
Would you prefer I try also for this one to reduce the delay to 200ms?

Would you prefer I try also for this one to reduce the delay to 200ms?

I think we should see how successful using the virtual tree control is. I expect we will need a mixture of these approaches. Tuning this delay time is going to be difficult, it will likely have a different optimal value on different computers. A third approach might be to do the list filtering in another (cancelable) thread. Restarting the work each time the filter gets updated.

@feerrenrut,
I have implemented the VirtualTree approach.
You can have a first look in accessolutions/nvda/inputGesturesVirtualTree / accessolutions/nvda@15478f898

After a lot of tweaks, it is slightly more efficient, but still not fully satisfying even on my race-horse development workstation.
It appears the most costly task is still to expand the categories as soon as there is a matching command.
I've tried to reduce the delay, but even 250 ms makes NVDA lag again when speed typing a filter text.
The current state of the branch shows an attempt to replace the delay timer by a separate thread: The result is even worse!

Thus, I would suggest either:

• To consider the 300 ms delay as a necessary small pain regarding to its benefit
• Not to expand the categories when there is a lot of matches, maybe by showing the number of matches next to the field. This would require an additional impact in the NVDA appModule to be vocalized, though.

I have implemented the VirtualTree approach.

Thanks for trying that out!

The current state of the branch shows an attempt to replace the delay timer by a separate thread: The result is even worse!

A surprising result, do you cancel this thread when typing resumes?

To consider the 300 ms delay as a necessary small pain regarding to its benefit

Yes, if none of these other options seem promising, we can certainly accept this approach.

do you cancel this thread when typing resumes?

Just looked at the branch, it seems you do. Though I'm concerned about accessing the gui from this other thread. I have commented on the commit.

do you cancel this thread when typing resumes?

Just looked at the branch, it seems you do. Though I'm concerned about accessing the gui from this other thread. I have commented on the commit.

It depends on which operations and which controls.
For this scope, wxPython/wxWidgets seems to handle just find delegating the necessary portions to its main loop, but consumes far too much time doing so.

Remember that the only real problem here (especially with VirtualTree) is expanding the categories.
All the rest happens quickly enough.

For a regular wxPython application, I'd just expand the categories one by one in the wx main thread, call wx.Yield every time and check for cancel conditions.
Within NVDA, its much harder to apply this classic technique since 2018.3 as wxPython 4 does not permit re-entrance of wx.Yield, which is called during the core pump cycle.

Would you prefer to keep the current PR as is, or that I cancel this one and file instead the Virtual Tree + delay timer? (Given that the separate thread version seems really not a viable option here.)

Remember that the only real problem here (especially with VirtualTree) is expanding the categories.
All the rest happens quickly enough.

If that's the case, perhaps do the filtering of categories that contain items that match to give an indication that filtering is working and only expand the categories after 300ms of no typing?

If that's the case, perhaps do the filtering of categories that contain items that match to give an indication that filtering is working and only expand the categories after 300ms of no typing?

Sounds worth trying. I'll test this approach on the VirtualTree branch and let you know.
Thanks

I'll test this approach on the VirtualTree branch and let you know.

It seems our conversations got a little mixed up between this PR and #10307

@JulienCochuyt can you confirm this PR is ready? I thought this would also be converted to a virtual tree?

@feerrenrut wrote:

It seems our conversations got a little mixed up between this PR and #10307

Indeed.

@JulienCochuyt can you confirm this PR is ready? I thought this would also be converted to a virtual tree?

It already improves the situation as is.
Unlike for PR #10307 - where expanding the categories was the big deal - it really is the retrieval of results which is costly here.
I'll probably try a few alternative approaches in the future, such as caching the unfiltered results upon first access - maybe in a VirtualTree if it helps. I'm not sure when I'll get time to, though.

I'm not entirely confident with this change. I might increasing this timeout doesn't have the effect that I would expect. I think I will need to look into it more.

@seanbudd, I can see that you have just added the new stale label.

1. Regarding the "stale" label: what does it mean exactly? There is no associated description; could you add one?

2. Regarding this PR: why is it stale?
   @JulienCochuyt requested a review 10 month ago, you added the blocked/needs-code-review label on Jul 5, 2022 and the CI does not show any merge conflict with master. Thus this PR should be reviewed or it should be indicated why this review cannot take place.

Thanks.

@CyrilleB79 - I have added the following description: "PR is stale/old - NV Access has missed reviewing this or this is an abandoned draft".
I have applied the label to 3 PRs which are stale, ready, and waiting on review.

Stale does not indicate merge conflicts or that it is blocked, we have separate labels for those 2 conditions.
Stale just indicates age.