search

LiamKarlMitchell / InhibitWindowsEvents

Prevent Mouse key Back/Forward and Windows Key so you can use them for Push to Talk keys in Discord and other apps.
MIT License
11 stars 0 forks source link

high cpu usage #5

Closed LordFoogThe4rd closed 2 years ago

LordFoogThe4rd commented 2 years ago

image

LiamKarlMitchell commented 2 years ago

So some people have experienced this issue on Laptops or CPU with less core it seems? (I'm sure everyone does but not so noticeable with more) I use a Sleep(0) in a loop which I thought would Yeild?

https://github.com/LiamKarlMitchell/InhibitWindowsEvents/blob/main/InhibitWindowsEvents/Source.cpp#L182

Better would be to make it a window/system tray and use message pump? I could use Sleep(1) but found it caused some lag and thats something no one wants.

So I think the problem is using a while loop indefinitely to process the messages from windows.

This is something I'de like to address but don't have the time right now might next month.

For further reading, I need to research making a system tray and windows app. https://social.msdn.microsoft.com/Forums/windows/en-US/a4d7e039-6654-4068-80b2-cd380530d92e/examples-using-win32-api-and-c-for-notification-tray-program?forum=vcgeneral https://stackoverflow.com/questions/68474486/creating-system-tray-right-click-menu-c https://www.codeproject.com/Articles/8059/CTrayIcon-System-Tray-Icon-Wrapper https://www.codeproject.com/Articles/74/Adding-Icons-to-the-System-Tray

Pull requests are welcome of course :)

LiamKarlMitchell commented 2 years ago

Hi @huangdangwibu , v1.0.2-alpha using GetMessage instead of PeekMessage if you'd like to try it.

image

Didn't get it to be a window app instead of console yet with nice system tray/ui etc. Still seems that is complex to do in C++ at least from what I was reading.

LiamKarlMitchell commented 2 years ago

If closing this was premature please let me know. My understanding is getMessage will block here as peekMessage did not block. If it blocks it shouldn't be using time on CPU unnecessarily.