Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle winEvents in-process #485

Closed
nvaccessAuto opened this issue Jan 1, 2010 · 7 comments
Closed

Handle winEvents in-process #485

nvaccessAuto opened this issue Jan 1, 2010 · 7 comments

Comments

@nvaccessAuto
Copy link

Reported by aleksey_s on 2009-11-29 08:45
Currently, NVDA sets out-of-process hooks to handle winEvents. though in most cases only few of them are actually used by NVDA, when application spams system with winEvents This makes NVDA lag because of unnecessary marshaling, context switchs and running of python code. Therefore in-process handling will improve performance in cases, when those bombings occur: when huge application starts/finishes, on page loads, in mozilla address bar and so on.

@nvaccessAuto
Copy link
Author

Comment 1 by aleksey_s on 2009-11-29 08:47
I propose my implementation to this problem: The code which handles and filters winEvents in-process in !NVDAHelperRemote. For storing events the non-locking circular buffer is used: this means that whenever in-proc part wants to add a winEvent to the storage, it will not lock other writers/readers.
!OrderedWinEventLimiter is also implemented in pure c++.
See bzr branch: http://bzr.nvaccess.org/nvda/winEventsInprocess

@nvaccessAuto
Copy link
Author

Comment 3 by mdcurran on 2009-12-02 01:19
I have had a look at the code.
Can you please provide some clear examples of where this code improves NVDA's performance. In theory I understand that you may be limiting context switches (though this is assuming that Window's isn't batching winEvents up itself anyway).
But are there some practical situations where you have clearly noticed improvement?

Also, I have some worries about 64-bit compatibility. Certainly your code will compile under 64-bit, but the winEvent_t struct is going to be a different size, due to HWND on 64-bit being double in size. (HWND is a typedef of HANDLE which is a typedef of void*, which is 64 bits, 8 bytes on 64-bit).
Perhaps I have missed how you handle this?

@nvaccessAuto
Copy link
Author

Comment 4 by aleksey_s on 2009-12-03 20:33
Actually, i've already provided the cases in ticket description. Most noticeable is address bar in firefox: NVDA lagged when you type something into the address bar. I did some tests which shown that firefox raises up to 600 events at a second. Lag is much lesser with my code. I suspect that now it just on firefox side.

Re 64 bit issue: This is my bad. I tried to make all 64-bit compatible but missed this one.
One solution i see so far is declaring handle as 8 byte integer on both platforms and type cast when needed.

@nvaccessAuto
Copy link
Author

Comment 5 by mdcurran (in reply to comment 4) on 2009-12-03 23:36
Replying to aleksey_s:

One solution i see so far is declaring handle as 8 byte integer on both platforms and type cast when needed.

I guess this would be fine.

@nvaccessAuto
Copy link
Author

Comment 6 by aleksey_s (in reply to comment 4) on 2010-04-09 12:12
Replying to aleksey_s:

One solution i see so far is declaring handle as 8 byte integer on both platforms and type cast when needed.

Here is quote from msdn (http://msdn.microsoft.com/en-us/library/aa384203%28VS.85%29.aspx):

64-bit versions of Windows use 32-bit handles for interoperability. When sharing a handle between 32-bit and 64-bit applications, only the lower 32 bits are significant, so it is safe to truncate the handle (when passing it from 64-bit to 32-bit) or sign-extend the handle (when passing it from 32-bit to 64-bit). Handles that can be shared include handles to user objects such as windows (HWND), handles to GDI objects such as pens and brushes (HBRUSH and HPEN), and handles to named objects such as mutexes, semaphores, and file handles.

So I'll do the truncation in 64 bit code.

@nvaccessAuto
Copy link
Author

Comment 7 by aleksey_s on 2010-12-06 20:19
Branch is updated to the latest changes. Could you please comment more on it? What do you feel isn't ready yet, or, in other words, what blocks this ticket?

@nvaccessAuto
Copy link
Author

Comment 8 by jteh on 2014-05-29 00:13
The IAccessibleHandler event code is tricky at best and any significant changes thereto have a tendency to cause unforeseen regressions. While this would certainly provide a theoretical performance improvement and Aleksey reports he sees a practical improvement as well, this issue isn't significant or frequent enough to justify the work involved in updating the code, tracking down potential regressions, etc. Therefore, I'm closing this for now, though it's certainly something to reconsider if this starts becoming more of a problem. All of this said, we do really appreciate the effort involved in this contribution.
Changes:
Added labels: wontfix
State: closed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant