Separate keyboard handling from GUI?


#1

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. 

Is that possible with JUCE?


#2

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!


#3

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


#4

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.

How many buttons?