Great Britain (UK)
Right so had a change to have a mess with this.
Firstly, I commented out the change as requested and re-ran with 1000hz mouse setting, it caused absolutely no change – weird.
Just for the sake of it, also ran without the change and back at 125hz – still very smooth and not particularly high CPU usage, all good (so the change I removed seems to make little difference to me in either situation).
The thing I was not quite understanding is, if we are saying we are swamping the program with events, why was the CPU not jumping to 100% (one core at least) while the events where processed... there are spikes, but only 1-2% over the whole CPU.
So I figured I would chuck in a Debug.WriteLine(), right on the MainForm_MouseMove so I could visually see the X and Y events being processed – this is where it gets interesting.
With the mouse set to 125hz, I move the mouse across the screen (left to tight) and see roughly 40 events... ok, cool.
Now bump it to 500hz and preform the left to right test again, this time, maybe 20 or so events – what the!
Ok so now try at the 1000hz setting, left to right test again... 4, 4 Events! What the hell!
So increasing the report rate is actually reducing the events raised by, well, quite a lot. This explains why there is no CPU spike, it’s not that there are too many events, there are substantially LESS.
This is what causes the huge “delay” on dragging the window, at 1000hz if you are lucky enough, an event will get raised “at some point” and the screen will jump to the new events position.
This is not a Media Portal issue; this is a Windows 10 issue
So with a little google, there are actually posts all over R.E 1000hz mice, it seems to have been noticed since Windows 10 1903, and not much interest from Microsoft thus far.
I did also come across someone mentioning enabling HPET (High precision timers) in the BIOS fixed the issue, but caused more CPU usage (as you would expect) - I did have that option (and enabled) on my previous Intel board, but I can’t see anything similar in my current (AMD) X570 setup.
There was also some mention of DPI & Report rates linked to windows mouse pointer speed – I did knock the mouse speed down to almost minimum while at 1000hz, it did improve a little but far from lag free, so at this point I don’t think there is anything that can be tweaked in Windows.
I wonder if this would improve if the main form was WPF, rather than WinForms? not a trivial upgrade I know.
Running the mouse at 125hz and the difference is substantial, Media Portal feels very quick – so glad to have got to the bottom after struggling with it for over a year now! Would you believe it’s even had an impact in games, the whole system just feels... better.
Firstly, I commented out the change as requested and re-ran with 1000hz mouse setting, it caused absolutely no change – weird.
Just for the sake of it, also ran without the change and back at 125hz – still very smooth and not particularly high CPU usage, all good (so the change I removed seems to make little difference to me in either situation).
The thing I was not quite understanding is, if we are saying we are swamping the program with events, why was the CPU not jumping to 100% (one core at least) while the events where processed... there are spikes, but only 1-2% over the whole CPU.
So I figured I would chuck in a Debug.WriteLine(), right on the MainForm_MouseMove so I could visually see the X and Y events being processed – this is where it gets interesting.
With the mouse set to 125hz, I move the mouse across the screen (left to tight) and see roughly 40 events... ok, cool.
Now bump it to 500hz and preform the left to right test again, this time, maybe 20 or so events – what the!
Ok so now try at the 1000hz setting, left to right test again... 4, 4 Events! What the hell!
So increasing the report rate is actually reducing the events raised by, well, quite a lot. This explains why there is no CPU spike, it’s not that there are too many events, there are substantially LESS.
This is what causes the huge “delay” on dragging the window, at 1000hz if you are lucky enough, an event will get raised “at some point” and the screen will jump to the new events position.
This is not a Media Portal issue; this is a Windows 10 issue
So with a little google, there are actually posts all over R.E 1000hz mice, it seems to have been noticed since Windows 10 1903, and not much interest from Microsoft thus far.
I did also come across someone mentioning enabling HPET (High precision timers) in the BIOS fixed the issue, but caused more CPU usage (as you would expect) - I did have that option (and enabled) on my previous Intel board, but I can’t see anything similar in my current (AMD) X570 setup.
There was also some mention of DPI & Report rates linked to windows mouse pointer speed – I did knock the mouse speed down to almost minimum while at 1000hz, it did improve a little but far from lag free, so at this point I don’t think there is anything that can be tweaked in Windows.
I wonder if this would improve if the main form was WPF, rather than WinForms? not a trivial upgrade I know.
Running the mouse at 125hz and the difference is substantial, Media Portal feels very quick – so glad to have got to the bottom after struggling with it for over a year now! Would you believe it’s even had an impact in games, the whole system just feels... better.
);
