Hello, I would like to document this once and for all.
Setup:
Windows 7
8 Core, 16 Thread CPU
60 FPS recording using OBS (encode was not bottlenecked)
Theme: Windows Basic (to allow 60 FPS recording)
The file will be available for nearly a year:
https://0x0.st/-NCb.mp4
After that:
magnet:?xt=urn:btih:bw2kshnqzg5ssr7otakq7k74qyefqx6l&dn=tixati-forumthread-6343-windowscursor_cpu.mp4&xl=9759666&fc=1
Below are the findings captured in the video:
6.25% usage indicates one full core/thread.
Video:
500Hz:
- notepad++:
* mouse movement: 0.50% peak
* mouse selection: 3.00% peak
* window dragging: 3.00% peak
- explorer.exe (desktop background):
* mouse movement: 0.50% peak
* mouse selection: 3.20% peak
- calc.exe:
* mouse movement: 0.60% peak
* window dragging: 2.60% peak
125Hz:
- notepad++:
* mouse movement: 0.20% peak
* mouse selection: 1.70% peak
* window dragging: 1.20% peak
* window dragging (including over calc.exe): 2.40% peak
- explorer.exe (desktop background):
* mouse movement: 0.20% peak (not on video)
* mouse selection: 2.20% peak (not on video)
- calc.exe:
* mouse movement: 0.11% peak (not on video)
* window dragging: 1.35% peak (not on video)
* window dragging (part of window is outside the virtual view area): 2.60% peak (not on video)
1000Hz:
- notepad++:
* mouse movement: 0.90% peak
* mouse selection: 3.90% peak (not on video)
* window dragging: 2.45% peak
- explorer.exe (desktop background):
* mouse movement: 0.70% peak
* mouse selection: 4.20% peak
- calc.exe:
* mouse movement: 0.50% peak
* window dragging: 2.40% peak
Mouse selection explorer.exe, from 125 to 1000 Hz:
1.9x CPU usage
Mouse movement explorer.exe, from 125 to 1000 Hz:
3.5x CPU usage
This goes to show this is a fundamental Win32 API issue. It affects EVERY program, your Windows desktop, the calculator, your browser etc.
From this we can deduct a power-saving tip:
reduce the mouse polling rate! especially when on battery power.
For each mouse movement event, that's 1000 times a second at 1000 Hz, an event is fired for apps to process, respond to and update their windows.
I believe programs could work around this 'bug' by practically rate-limiting how often they truthfully update on each mouse event.
You only notice this with Tixati, because its GUI is indeed a bit heavier than usual programs. In addition, as Tixati users have found earlier: one of Windows 10 Updates introduced a regression which led the GUI drawing procedure to be
much more resource intensive than before (Windows 7 unaffected).
I have now reduced my own mouse polling rate from 500 Hz to 250 Hz. 1000 Hz was always outright insane, but as proven above, neither is 500 Hz beneficial. 250 Hz appears to be the perfect compromise nowadays.
Users: Tweak your settings, use better Operating Systems that are not Windows.
Tixati Devs: Since Tixati is main-thread dependent, it's ultimately something you'd want to work around :|
PS: Further, I have uncovered two more peculiarities:
1) Dragging the foreground over background windows makes the background windows still respond to the event, consuming CPU even though practically unnecessary
2) Dragging a window such that a part of it is 'outside' the viewable area, skyrockets the CPU usage again, seemingly without a valid reason.
- notaLamer -
