Sluggish "mouse over" detection

[99999]

XMBC Version: v2.18.1
Windows Version: Windows 10 17763 (1809)
Mouse Information (brand/model): Logitech
Computer Information:
Did the problem occur after an upgrade of XMBC or Windows?: Yes, of XMBC
How long have you used XMBC?: Several years
What language and keyboard layout do you use in Windows?: English

Clear description of the problem:
The "mouse over" detection is sluggish in the latest version. Not sure if it started in 2.18 or 2.18.1.
Here's a demo video:
https://imgur.com/a/jY0DAwW

My settings for Chrome are:
https://imgur.com/GPcXqhu

So as you can see, if I move the mouse too fast onto Chrome, it's not being detected, and the scroll I defined doesn't work.

I also see another issue which is difficult to reproduce but might be relevant: I use Visual Studio Code which is built with Electron (based on Chromium), so it has the same class names. but the process name is different, not chrome.exe. Nevertheless, sometimes when I scroll on Visual Studio Code, it launches the scroll that I defined with XMBC. I suspect that it confuses the process name and thinks I'm pointing on Chrome for some reason.

[phil]

The process over has changed in 2.18, but it has always been intentionally lagged to some extent - that is, because mouse over detection is quite CPU heavy, it runs on a timer not every time the mouse moves by a single pixel... The timer fires 50ms after the mouse movement (if I recall correctly a - Im at work and don't have access to the code).
When you move the mouse very quickly, by the time the timer fires, the pointer may not be over the same area. In this case however there appears to be a separate issue with chrome when its maximized (sometimes it detects, sometimes no, esp if the cursor is right at the top of the monitor) - This may well be an error (unlikely to have changed in 2.18 but maybe it did).

The timer thing is not a change (its been that way for ages) but maybe I tweaked the actual time values - I'll have to check. The other possibility is that the actual time it takes to do the detection may well have changed as quite a lot of work went into that. In theory it should be faster/more efficient but that's only in theory, and maybe when doing the window regions bit, it may be slower - not sure but there were several bugs in the window region/specific area code!). Either way, it appears to have made an obvious <negative> difference for you which is not good.

Also note that the actual highlighting in the settings window is done via a message posted to the window, so the highlight in the display will lag more than the actual detection itself.

Can you try these settings and see if it makes any difference (I suspect it wont but as the code path is slightly different, its worth a try)

xmbcapp.png

Also try checking all four region boxes (it may detect in the wrong place but it will be faster - so curious to see the result).

Thanks,
Phil

[99999]

Can you try these settings and see if it makes any difference (I suspect it wont but as the code path is slightly different, its worth a try)
xmbcapp.png
Also try checking all four region boxes (it may detect in the wrong place but it will be faster - so curious to see the result).

Tried both, same problem

[phil]

As I said, I expected it wouldn't make a difference, but I needed to be sure.
I'll try and have a look when I get home from work and get back to you if I find anything of note.

[phil]

OK Some progress...

Looks like its nothing to do with my timers.
Actually what is happening, is that the reported mouse cursor position is incorrect (when chrome is maximized) and the mouse moved rapidly to the top of the screen.

I'm seeing negative Y position values (-3, -5 etc) - ie, off the top of the monitor! This shouldn't be possible of course but I guess I have to thank Microsoft for this one!

So then it fails to find a profile... Until the mouse moves within the are again. I think it was less of a problem in 2.17 because it checked more frequently (when it didn't really need to) such that it reduced the effect of this problem (the problem was still there of course, it just didn't appear so blatantly.).
There is a relatively simple workaround from my point of view - and that's if no window is detected at all (not even the desktop window) to retry using the current mouse cursor position (which when I ask Windows for that, appears correct (and different from what Windows told me in the first place - joy!)

So thats 2.18.2 on the cards then!

Thanks,
Phil

[99999]

Hmm, interesting. Where do you get the negative values? In a low level mouse hook (WH_MOUSE_LL)? Perhaps it's best to always call GetCursorPos?

[phil]

Yes... negative absolute position values in the low level mouse hook (outside the screen area).. and yes, I changed it to call GetCursorPos() which appears to work here but there may still be an issue after your feedback to my PM this morning...

EDIT As well as the debug log I asked for, can you please send me a copy of your profile just so I can be sure I'm working with the same thing!

Regards,
Phil