Hello Jules,
When running the Demo application, there is the FPS limit in 2D Rendering demo section (and it’s not only there):
startTimerHz (60);
I understand that the 60Hz value is a kind of fallback one. And I would not even notice that if I don’t have a display that supports 165Hz with NVIDIA G-SYNC technology. It looks choppy when an animation runs with the 60 FPS limit on a higher display refresh rates. So, I slightly modified the demo app for windows with this code:
#include "../JuceDemoHeader.h"
namespace Win
{
#include <Windows.h>
}
...
void setDemo (GraphicsDemoBase* newDemo)
{
if (currentDemo != nullptr)
removeChildComponent (currentDemo);
currentDemo = newDemo;
if (currentDemo != nullptr)
{
addAndMakeVisible (currentDemo);
{
int currentDisplayRefreshRate = 60; // 60Hz as a fallback initially
Win::DEVMODE devMode;
std::memset(&devMode, 0, sizeof(devMode));
devMode.dmSize = sizeof(devMode);
// (unsigned)-1 == ENUM_CURRENT_SETTINGS
if (Win::EnumDisplaySettings(nullptr, static_cast<unsigned>(-1), &devMode))
{
currentDisplayRefreshRate = devMode.dmDisplayFrequency;
}
startTimerHz(currentDisplayRefreshRate);
}
resized();
}
}
For Linux it would look like:
Display *dpy = XOpenDisplay(NULL);
Window root = RootWindow(dpy, 0);
XRRScreenConfiguration *conf = XRRGetScreenInfo(dpy, root);
short current_rate = XRRConfigCurrentRate(conf);
Unfortunately, I don’t know yet how to retrieve the refresh rate in OSX, iOS and Android.
Anyway, I suggest to generalize the current display refresh rate retrieval in JUCE and use it as the FPS limit. I think it is a good idea just to know the refresh rate and it’s worth a method in JUCE for that purpose.
Thanks,
Arlen.