I have not checked this on other platforms; it may be macOS specific.
This is tested on a MacBook Pro Retina.
This issue is reproducible with the JUCE demo on the master branch of the ROLI JUCE repo.
What I am finding is that if you run the JUCE Demo (in either Debug or Release) and switch to the 2d Rendering Demo the following will happen:
If the mouse cursor is NOT over the window, then the 2d Demo animates smoothly and the “Actual FPS” readout sits right at 60 FPS (plus or minus a little noise < 1FPS).
If the mouse cursor is over the window (not moving, just within the bounds of the window), the animation “stutters” perhaps 2 times per second. The “Actual FPS” readout jumps between 50 and 60 FPS (throughout the range).
If you select the OpenGL demo, the 3d Content animates smoothly whether or not the mouse cursor is within the bounds of the window. If, you enable the “Draw 2d graphics in the background” you revert to the behavior that is seen for the 2d Rendering demo (e.g. smooth if the mouse is outside of the window, and stuttering if the mouse is within the window). In this case the stutter occurs for both the 2d and the 3d Content.
I am not sure how to trace where this is coming from.
Obviously, this is less than ideal as it causes the UI to stutter while the user is interacting with it.
I think that it is very interesting that the stuttering doesn’t happen with the 3d Content in the OpenGL demo, but it does if the 2d drawing is turned on. Perhaps that is canary for someone who is more familiar with the code…
This is just a guess here: the 3d content isn’t using a timer to rotate the teapot. It’s using OpenGL’s idle callbacks which run on the OpenGL thread. The 2d content will update with a timer on the message thread. So if other messages start flooding the message thread (such as mouse movements), the timers will fire with some jitter - maybe resulting in the stuttering that you are seeing.
I don’t think that your guess is correct in this case.
In the case I am seeing, the mouse is not moving. It is just parked over any part of the window. If the mouse is not within the bounds of the window the stuttering stops.
For the OpenGL demo, if you look at the code, you’ll see that indeed, the 3d Content is rendered on the OpenGL thread, but when the 2d Checkbox is ticked, that 2d content is also rendered on the OpenGL thread as a call from the renderOpenGL method.
See:
It turns out that if you comment out line 790:
Then the stuttering won’t occur when the mouse is over the window.
So, it seems to be related to the actual rendering, and not any of the state management…
Can’t really think of anything that would cause that issue other than the amount of OpenGL calls to draw that path will be quite intensive. Maybe it’s just too much for your GPU.
No; I don’t think so. Remember, the problem appears without using OpenGL at all (it happens just using the JUCE 2d stuff, and doesn’t happen if there is no 2d rendering under the OpenGL).
OK. Well, if I can come up with a better reproducer or more data, I’ll let you know. I admit that this is a weird one. It could also be related to the specific version of macOS I am testing on (10.11.6) and may have been fixed in the OS in later versions; it does seem like it would be OS related in some way given the interaction with the position of the mouse cursor.
