Reported by jteh on 2014-01-31 07:25
We do filter some events (e.g. MSAA show events are restricted to certain window classes), but for the most part, we unconditionally handle all events we listen for. This can lead to poor performance if an unresponsive (or very slow to respond) background application fires an event. One example is an application performing some task while displaying a progress bar, but the task blocks the GUI for long periods of time. Even if you switch to another app and have reporting of background progress bars disabled, NVDA will freeze for long periods in this situation. To work around this, we should stop handling most events from background processes by default. Because some code might need background events, we should provide a mechanism to request specific events for specific processes.
Blocked by #3849, #3850, #3897, #3899, #3905, #4001
Blocking #3964
Reported by jteh on 2014-01-31 07:25
We do filter some events (e.g. MSAA show events are restricted to certain window classes), but for the most part, we unconditionally handle all events we listen for. This can lead to poor performance if an unresponsive (or very slow to respond) background application fires an event. One example is an application performing some task while displaying a progress bar, but the task blocks the GUI for long periods of time. Even if you switch to another app and have reporting of background progress bars disabled, NVDA will freeze for long periods in this situation. To work around this, we should stop handling most events from background processes by default. Because some code might need background events, we should provide a mechanism to request specific events for specific processes.
Blocked by #3849, #3850, #3897, #3899, #3905, #4001
Blocking #3964