Improve responsiveness of input and focus by pumping immediately instead of after a delay.#14701
Conversation
|
I realise 10 ms is a pretty small difference, but even that potentially matters when it comes to feeling snappy, especially since there are other sources of delay we can't control (cross-process communication, application delays, minimum audio latency, speech synth processing, etc.). That said, given that we are talking about such a small delta, it's hard to be sure this makes a practical difference other than looking at the numbers. |
|
Hi, Even if it's only a 10ms boost, I think it's pretty cool. |
…ead of after a delay.
|
There is cumulative effect when thinking all users daily use. |
See test results for failed build of commit ee20a6c022 |
michaelDCurran
left a comment
There was a problem hiding this comment.
This looks good to me.
Several system tests that generally don't fail, did fail on the first run, but then succeeded on the second. We'll want to keep an eye on this.
|
I can confirm that this improves performance in MS Word significantly, I tested with a 164 pages document with many large tables and images and including converted text from through OCR which sometimes usually slowed down NVDA. Now it works really fluently even with UIA disabled. Still there is a noticeable difference when reporting pages in document formating settings is enabled or disabled. |
…ely instead of after a delay. (#14701)" (#14925) This reverts pr #14701, commit cc8b5ad Link to issue number: Fixes #14753 May fix #14803 Summary of the issue: After the merging of pr #14701, It was reported in #14753 that with input help mode on and moving your finger around the touch screen, many errors would be logged and eventually input help mode would be disabled. The recursion itself was caused by the core pump's Notify method calling request directly, which itself calls Notify. The obvious fix would be to wx.CallAfter the call to request. However, this then caused the WX event loop to fill up with responses to these call afters, and due to the way the wx event loop works (msgWaitForMultipleObjects waiting on a pending event win32 event), the event loop never ended up getting a chance to process OS and 3rd party messages. And because we monkeypatch CallAfter to PostMessage (in case we are in a win32 modal or menu and don't wake up) the win32 message queue was being filled completely thus not allowing future messages to be posted. @jcsteh and I have considered several different ways of trying to work around this. Most of which have not been successful. There are probably more things we could try, but for now it is better to revert until we can get this right. Description of development approach Fully reverts pr #14701 for now.
…ely instead of after a delay. (nvaccess#14701)" (nvaccess#14925) This reverts pr nvaccess#14701, commit cc8b5ad Link to issue number: Fixes nvaccess#14753 May fix nvaccess#14803 Summary of the issue: After the merging of pr nvaccess#14701, It was reported in nvaccess#14753 that with input help mode on and moving your finger around the touch screen, many errors would be logged and eventually input help mode would be disabled. The recursion itself was caused by the core pump's Notify method calling request directly, which itself calls Notify. The obvious fix would be to wx.CallAfter the call to request. However, this then caused the WX event loop to fill up with responses to these call afters, and due to the way the wx event loop works (msgWaitForMultipleObjects waiting on a pending event win32 event), the event loop never ended up getting a chance to process OS and 3rd party messages. And because we monkeypatch CallAfter to PostMessage (in case we are in a win32 modal or menu and don't wake up) the win32 message queue was being filled completely thus not allowing future messages to be posted. @jcsteh and I have considered several different ways of trying to work around this. Most of which have not been successful. There are probably more things we could try, but for now it is better to revert until we can get this right. Description of development approach Fully reverts pr nvaccess#14701 for now.
Link to issue number:
None.
Summary of the issue:
Currently, everything in NVDA, including responding to keyboard input and focus changes, goes through the core pump. The core pump is always run with a slight delay. Assuming nothing else is already queued, any input or focus change will not be processed for a minimum of 10 ms. In reality, it's potentially longer due to the system timer resolution and the fact that timers are low priority messages. We should be aiming for the fastest possible response to user input and focus changes.
Description of user facing changes
NVDA will respond slightly faster to commands and focus changes.
Description of development approach
_immediateargument which is passed to requestPump. It is_prefixed to mitigate conflicts with keyword arguments intended for queued functions.Testing strategy:
I used "time since input" logging to measure the differences in times before and after the change in various situations:
This can be quite variable, so it's only a rough guide, but the results are pretty suggestive.
Known issues with pull request:
None.
Change log entries:
Bug fixes
NVDA now responds slightly faster to commands and focus changes.
Code Review Checklist: