JUCE Demo improvement for a display refresh rate


#1

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.


#2

That may be the case but what you’ve got there is only a fraction of the work that’d be involved in implementing this… As well as all the other platforms, it’d need to handle moving windows across multiple monitors, changes in refresh rate etc. It’s a good FR but can’t promise to find time for it right away.


#3

Of course, Jules. I didn’t present a complete solution to the problem. I just supposed it would be a great addition to the JUCE framework just to have that functionality out of the box.