My stand-alone application has GUI elements, which listen to the computer keyboard. That is working fine. BUT: I realized, if the GUI has a lot to do (a lot of redrawing going on) then the keyboard input is affected. It gets laggy.
Therefore I would like to create a separate thread, which does nothing else, but listen to keypresses. This key-press thread should be independent of the GUI-loop.
It's not possible with any toolkit, they all process key events on the message thread.
The golden rule of GUI programming is to never block the message thread - it's your blocking operations that need to move to another thread, not the keyboard handling!
Hmm…
In my case the blocking operation is the GUI itself. I have a Juce viewport. Inside of it are a lot of buttons. Everytime the viewport scrolls, the buttons get redrawn. And during the redraw the keyboard input gets laggy.
But maybe I can force the redraw/paint to happen on a separate thread? Like some kind of asynchronous redraw… Hmmm
Slam a profiler on it and see what's taking all the time. You might be able to optimise the button painting by subclassing Button and creating a very efficient one using a separate thread, faster code, caching in an Image or using OpenGL.