Separate keyboard handling from GUI?

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?

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!

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.

How many buttons?