Revert "Improve responsiveness of input and focus by pumping immediately instead of after a delay. (#14701)"#14925
Conversation
|
@michaelDCurran, when you get some time, it'd be great if you can document what you tried and how it failed so I have a chance of fixing this. We discussed this a bit on Slack, but, for example, I don't know why the while loop approach failed. One of your concerns was potentially blocking the core for too long. I don't see how a timer would fix this. Sure, it yields to the message loop more often, but that is effectively just kicking the can down the road to the next pump, where it will process a large batch of queued scripts without yielding. |
|
@jcsteh see NV Access branch i14753. There are several various commits there, including the while loop one I think. |
See test results for failed build of commit 3b1ce99eb1 |
…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.
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.
An example rrror was:
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.