UI API called on a background thread

I’m calling isMouseOver() from a paint method … which seems like it should be fine.

However, since I am using openGL to paint, the call is made on the GL thread not the main message thread, and so I get this error now.

Is this actually a major issue? Or something I can ignore?

If it is a major issue, then how should one go about calling these sorts of functions from openGL thread (synchronously, hopefully)? There are, of course, a number of other examples (guessing there is a whole bunch of functions that would trigger this, as I’ve seen a few now).

Why not just track mouseOver via the mouse callbacks, and just access that state in paint?

Well, in this case I’ve removed the mouse listener from this item since it’s parent is listening to the mouse events, etc. etc.

So, I could probably make it work in the way you mention, and there are a few other ways to fix it too …

But this doesn’t give me clarity, since what I’m wondering is if/why these calls are problematic from the paint call? Is there a real need to make these calls explicitly from the MM thread? I’m getting a Main Thread checker message, but would like to know how seriously to take the message … is it likely to cause some runtime error? If so, why not add a jassertfalse in there?

My gut says there is a good reason for the way things work, but that is a complete assumption on my part based on the maturity of JUCE.

Of course … I suspect so as well, just hoping to get some better understanding here :slight_smile:

By looking at the code, my guess is because it accesses a variety of things that can be modified in the context of the MM thread. Desktop::getInstance().getMouseSources(), ms.getComponentUnderMouse(), isParentOf (c), etc…

Ah, and Desktop:: items can’t be modified from other threads eh? That makes sense. Guess I had better refactor some things ;(

1 Like

Hmm, I do check the isMouseOver() function in paint functions in Apps running on JUCE’s OpenGL, and although the “Main Thread Checker” bit from apple spits out some warnings, I’ve never had an actual problem with it.

Have you verified this is from isMouseOver()? Just using JUCE’s OpenGL component rendering by default will give you the warnings for internal reasons:

Also, for the reasons based on Jules’ comment in that thread, you’re safe to use these UI calls like isMouseOver() as long as component painting is enabled… since component painting locks the main thread

1 Like