home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 2
General
GUI incredibly slow Performance
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="Trigg3r" data-source="post: 1264392" data-attributes="member: 164576"><p>Right so had a change to have a mess with this. </p><p></p><p>Firstly, I commented out the change as requested and re-ran with 1000hz mouse setting, it caused absolutely no change – weird. </p><p></p><p>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). </p><p></p><p>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. </p><p></p><p>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. </p><p></p><p>With the mouse set to 125hz, I move the mouse across the screen (left to tight) and see roughly 40 events... ok, cool. </p><p></p><p>Now bump it to 500hz and preform the left to right test again, this time, maybe 20 or so events – what the! </p><p></p><p>Ok so now try at the 1000hz setting, left to right test again... 4, 4 Events! What the hell! </p><p></p><p>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. </p><p></p><p>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. </p><p></p><p>This is not a Media Portal issue; this is a Windows 10 issue </p><p></p><p>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. </p><p></p><p>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. </p><p></p><p>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. </p><p></p><p>I wonder if this would improve if the main form was WPF, rather than WinForms? not a trivial upgrade I know. </p><p></p><p>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.</p></blockquote><p></p>
[QUOTE="Trigg3r, post: 1264392, member: 164576"] 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. [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 2
General
GUI incredibly slow Performance
Contact us
RSS
Top
Bottom