Hm, I’m on Windows here…
However, this is getting strange…
To summarize… What I already have:
HighPresisionTimerThread (60Hz):
-
Box2D update
-
Render to offscreen target using SW renderer
-
Send the image over artnet.
-
Create a copy of the rendered image with getCopy() member function
-
Inform the component it should repaint and set it’s image to this copy via C++11 lambda and MessageManager::callAsync, which looks like this:
img = img.createCopy();
MessageManager::callAsync(= {
this->imgComponent.setImageWithBroadcast(img);
this->imgComponent.repaint();
});
MainThread:
imgComponent which is in fact a child of ImageComponent gets repainted because it’s image was set to a new one.
The point is that if I log the time in milliseconds (getMillisecondCounter()) at the end of the timer thread, it’s almost always exactly 16ms which is OK.
If I log the time at the end of the image paint function I get something between 15 - 24 ms which I believe is just fine. I can also tell no frames are missing because I also log the index of the image I render and no index is missing at all.
So far so good, right? That’s what I wanted to achieve…
Well, yes. But that’s not what I am seeing. It still lags like twice a second… I can clearly see that on the screen (don’t know about the art-net output at this point, I will try that later). So, if the end of the paint function happens to be exactly where it should be and no images are left out… Than the lag has to happen somewhere after that. Is it possibly that the frame-buffer switch (or however the JUCE rendering on Windows work) is slightly delayed every once in a while? What could be a reason of that? No I know that the artifacts I was seeing all that time are not even related to how I render it.
I think I can also see the same effect with AnimationAppExample from the JUCE examples directory. It’s just not so obvious since the movement is not that simple and the resolution is not that low. But even then I can see it stutter every once in a while.
I know that JUCE is not a game engine and that this is not a standard use-case, but I would still like to know what happens and why… I guess I wouldn’t encounter this on Mac right? Too bad I don’t have one to try that…
Also note that in my Window I have also another component that renders the game as well, but this one uses Box2DRenderer which is somewhere in JUCE and is called normally from the main thread. On this component the stuttering happens as well and I believe that it happens at the same time as on the ImageComponent(it’s impossible to tell that because you know… There are 60 frames per second). It really looks like the lag is caused by something else after everything is painted. To me, it looks like the frame buffer switch is delayed for some reason…