XMBC introduces a tiny delay to button clicks?

x64 Replacement/Alternative to Microsoft's IntelliMouse application.
Forum rules
Please read the forum rules before posting for the first time.
The more information you can provide, the quicker and more accurately someone can help.
NOTE: To reduce spam, new users can not post links or images until they have at least 4 posts.
Post Reply
Ampa
New User
Posts: 4
Joined: Tue Mar 10, 2020 10:46 pm

XMBC introduces a tiny delay to button clicks?

Post by Ampa »

XMBC Version: 2.19.1
Windows Version: 10.0.18363
Mouse Information (brand/model): J-Tech Digital V628
Relevant Computer Information (CPU, RAM etc): Ryzen 2700x 16GB SSD
Did the problem occur after an upgrade of XMBC? (If so, from what version?): Perhaps. 2.18 > 2.19
Did the problem occur after a Windows update/upgrade? (If so, from what version?): Don't think so.
How long have you used XMBC?: Many years
What language and keyboard layout do you use in Windows?: En-GB QWERTY

Clear description of the problem - try and include as much information as possible, including what button and mappings you are having problems with (if applicable).:

Recently I have the feeling that XMBC is adding a tiny delay to my mouse clicks.
I notice this when trying to resize a window by dragging the edge.

With XMBC enabled: I click and drag, and ~80% of the time I miss!
Instead of resizing the window I end up dragging a selection box that starts just outside the window that I was trying to resize.

With XMBC disabled: I perform exactly the same procedure, and succeed at least 90% of the time.

I am only using one layer, with a few simple actions.
I have button chording on my Left mouse button.

My hunch is that this started when XMBC introduced different pointers to show chording, button holds etc, which was #581 in 2.19
I have turned of the options to change the pointer in settings, but this makes no difference.

Any thoughts?

Thanks
Last edited by Ampa on Sat May 23, 2020 1:00 am, edited 1 time in total.

User avatar
Kukurykus
Fanatic
Posts: 388
Joined: Sat Jul 02, 2016 1:15 pm

Re: XMBC introduces a tiny delay to button clicks?

Post by Kukurykus »

What's application name where you resize window / drag selection box?
HAMA Roma, Rapoo 3920P
Windows 10 x64, Intel i5-4670K @ 3.40GHz, 8GB,
Intel(R) HD Graphics 4600, Intel SSD 179 GB HDD

Ampa
New User
Posts: 4
Joined: Tue Mar 10, 2020 10:46 pm

Re: XMBC introduces a tiny delay to button clicks?

Post by Ampa »

All windows are affected.

As a test open Notepad and place it centrally on the desktop, then try to click drag the right (or left) edge to resize the window.

There is no other window behind Notepad, so a selection marque is drawn on the desktop itself.

Ampa
New User
Posts: 4
Joined: Tue Mar 10, 2020 10:46 pm

Re: XMBC introduces a tiny delay to button clicks?

Post by Ampa »

I would post a GIF showing the effect... but I need 2 more posts!

User avatar
phil
Site Admin
Posts: 6466
Joined: Sun Apr 06, 2003 11:12 pm

Re: XMBC introduces a tiny delay to button clicks?

Post by phil »

Hi,

XMBC in its nature will always introduce a small delay (but that may not be the actual problem here).
Of course, as it does more (or your configuration asks more of it) the tendency will be for that delay to increase, and modifying cursors is quite resource intensive (relative to not doing it anyway). For example, I see the processes CPU usage go up by 1 or 2 percent when clicking a button that has chording set with the cursor images being adapted. This has to be done on the fly (although the images are cached),

However, if your turn the options OFF it should work as it did before (it has one more IF statement to check that option but that's not at all expensive). So there may be something else at play here - or the option may not be working properly. There were issues, and I've just released 2.19.2 which fixes several issues in this area (mostly with resource leaks which wont help) so I would ask you to try 2.19.2 before anything else (check for updates should find it now).

I generally don't recommend changing the left mouse button at all in XMBC, one because if things go wrong it can be tricky to get out of trouble but also for reasons such as this.

For chording to work XMBC has to:
  • BLOCK the first button down message...
  • Work out if you start a chord (if you press another button then its a chord, or if you move the mouse more than 5 pixels OR you release the first button, its not a chord)
  • If you didn't start a chord, it has to re-inject the original button down message that it blocked. If by that time (between pressing and releasing the button/aborting the chord by moving the mouse) the cursor has moved enough, the injected message won't hit the target (window frame).
However, all of that has applied to ALL versions of XMBC since chording has been added. It shouldn't be any worse in 2.19 than it was in 2.18 - unless maybe I adjusted the "zone" for movement breaking the chord (EDIT: No I didnt change that its still 5 pixels) - that's possible I will have to check the history on that. and Maybe the increased things its doing makes enough of a difference to cause you a problem.

I suspect if I were to chord my left button, I would see similar effects - I'll give it a try but I'd appreciate some feedback based on 2.19.2. I can also provide links to 2.18.8 if you need them so we can rule in/out your theory that its gone wrong between 2.18 and 2.19 (which kind'a does make sense).

Out of interest, if you open task manager and look on the details tab, when you press the button (repeatedly), does XMBC's CPU usage go up significantly?

NOTE: Ive removed you for the image/url post limiting group (its only there to prevent spam bots) - so you can post immediately if you want to.

EDIT: With 2.19.2 I'm still seeing increased CPU load (over 2.18.8) even when those options are turned off - so XMBC is still using more CPU (and thus potentially more delay) - I will have to dig into it in more detail to figure out why!
--[ Phil ]--
--[ Administrator & XMBC Author ]--
Logitech G9, Logitech MX518, Microsoft Intellimouse, Trust 16341 BT Mouse
Windows 10 x64, Intel i5-9600k, Asus Z390-ROG, 16GB DDR4,
nVidia GeForce GTX 970, Evo 970 500Gb NVME, 2x2TB WD Black (RAID1)

User avatar
phil
Site Admin
Posts: 6466
Joined: Sun Apr 06, 2003 11:12 pm

Re: XMBC introduces a tiny delay to button clicks?

Post by phil »

Having enabled chording on my left buttons, I struggle to resize any window.
And its because of this 5 pixels movement before the chord is cancelled... I suffer exactly the same problem in 2.18.8 and 2.19.x - so either you have a different problem or its compounded.
--[ Phil ]--
--[ Administrator & XMBC Author ]--
Logitech G9, Logitech MX518, Microsoft Intellimouse, Trust 16341 BT Mouse
Windows 10 x64, Intel i5-9600k, Asus Z390-ROG, 16GB DDR4,
nVidia GeForce GTX 970, Evo 970 500Gb NVME, 2x2TB WD Black (RAID1)

User avatar
Kukurykus
Fanatic
Posts: 388
Joined: Sat Jul 02, 2016 1:15 pm

Re: XMBC introduces a tiny delay to button clicks?

Post by Kukurykus »

I think the problem is because after we click one button, then other (in chord mode) we immediately move our hand to resize window. Unfortunately we do it (although naturally) faster than XMBC is establishing the chord, so when mouse cursor is already few pixels outside of window corner.

That's very small delay, that does not exist without XMBC when resizing window. In conclusion if that delay could be some way shrinked to minimum (if possible), we would not have to wait intentionally some extra milliseconds (up to one second) with no move (after last click) to make sure the side effect will not occur.

It wouldn't eliminate issue completely, but at least that would be less annoying, than having it so often.
HAMA Roma, Rapoo 3920P
Windows 10 x64, Intel i5-4670K @ 3.40GHz, 8GB,
Intel(R) HD Graphics 4600, Intel SSD 179 GB HDD

User avatar
Kukurykus
Fanatic
Posts: 388
Joined: Sat Jul 02, 2016 1:15 pm

Re: XMBC introduces a tiny delay to button clicks?

Post by Kukurykus »

Updating 2.19.2 from tray opens progress bar that doesn't move forward. After trying to install full version I got from system an information which I never recieve for XMBC, do I want to install it from dubious source.
HAMA Roma, Rapoo 3920P
Windows 10 x64, Intel i5-4670K @ 3.40GHz, 8GB,
Intel(R) HD Graphics 4600, Intel SSD 179 GB HDD

User avatar
phil
Site Admin
Posts: 6466
Joined: Sun Apr 06, 2003 11:12 pm

Re: XMBC introduces a tiny delay to button clicks?

Post by phil »

Kukurykus wrote:
Sat May 23, 2020 1:50 pm
Updating 2.19.2 from tray opens progress bar that doesn't move forward. After trying to install full version I got from system an information which I never recieve for XMBC, do I want to install it from dubious source.
Can only assume that's because its using a new code signing certificate that Windows smartscreen hasn't seen much before... (Its the same certificate provider, and the same publisher name but what should that matter!).
Nothing I can do about that I'm afraid, other than wait for smartscreen figures its safe and stops prompting... :( Thanks Microsoft!
PS. That should have been in a new thread really - I'm sure someone else will make one :)!
--[ Phil ]--
--[ Administrator & XMBC Author ]--
Logitech G9, Logitech MX518, Microsoft Intellimouse, Trust 16341 BT Mouse
Windows 10 x64, Intel i5-9600k, Asus Z390-ROG, 16GB DDR4,
nVidia GeForce GTX 970, Evo 970 500Gb NVME, 2x2TB WD Black (RAID1)

User avatar
Kukurykus
Fanatic
Posts: 388
Joined: Sat Jul 02, 2016 1:15 pm

Re: XMBC introduces a tiny delay to button clicks?

Post by Kukurykus »

XMBC 2.19 Released is locked so I continued here where you mentioned of 2.19.2
HAMA Roma, Rapoo 3920P
Windows 10 x64, Intel i5-4670K @ 3.40GHz, 8GB,
Intel(R) HD Graphics 4600, Intel SSD 179 GB HDD

User avatar
phil
Site Admin
Posts: 6466
Joined: Sun Apr 06, 2003 11:12 pm

Re: XMBC introduces a tiny delay to button clicks?

Post by phil »

Yes it is locked, to make people start a new thread for new issues... sigh!
--[ Phil ]--
--[ Administrator & XMBC Author ]--
Logitech G9, Logitech MX518, Microsoft Intellimouse, Trust 16341 BT Mouse
Windows 10 x64, Intel i5-9600k, Asus Z390-ROG, 16GB DDR4,
nVidia GeForce GTX 970, Evo 970 500Gb NVME, 2x2TB WD Black (RAID1)

Ampa
New User
Posts: 4
Joined: Tue Mar 10, 2020 10:46 pm

Re: XMBC introduces a tiny delay to button clicks?

Post by Ampa »

Hi Phil,

Thanks for the comprehensive replies.

I have updated to 2.19.2 but as you correctly surmise the issue still exists.

I wonder why I am only noticing this now after years of XMBC use?!

I have recently changed to a 4k monitor, which I run with 150% scaling. I also scale the mouse pointer (350% from memory!)

I could experiment to see whether those things affect performance.

User avatar
phil
Site Admin
Posts: 6466
Joined: Sun Apr 06, 2003 11:12 pm

Re: XMBC introduces a tiny delay to button clicks?

Post by phil »

The higher DPI could be a factor, because the cursor is moving further/faster perhaps.

XMBC attempts to work around the issue of cancelling the chord when the mouse moves, by:
  1. Setting the cursor position back to when the chord started,
  2. Sending the button down
  3. Finally moving the cursor to where it just was before step 1...
The problem is, if the cursor is moving quickly (as happens on a drag operation) it frequently has already moved further between steps 1 and 2.
I have just been looking at this and I can improve it (locking the X & Y axis before step 1 and unlocking after step 3) That will/does help a lot but I think its still not perfect (perfection may be an impossible goal here!). I will put that change into the next beta and you can perhaps have a play with it.

If you want to try 2.18.8 on the same spec (same DPI etc) and see if its any different, here is a link!
--[ Phil ]--
--[ Administrator & XMBC Author ]--
Logitech G9, Logitech MX518, Microsoft Intellimouse, Trust 16341 BT Mouse
Windows 10 x64, Intel i5-9600k, Asus Z390-ROG, 16GB DDR4,
nVidia GeForce GTX 970, Evo 970 500Gb NVME, 2x2TB WD Black (RAID1)

Post Reply