feature request (breaking): monitor refresh rate as double instead of u32

[mpalomas]

Hi,

Currently, the monitor refresh rate seems to be a u32, fetched like this:

foundMode.refreshRate = (u32)XRRConfigCurrentRate(conf);

On my system, when I print it I get 120. But there are use cases where you need the accurate refresh rate, which is never exactly 60/120/240...

Again on my system, the accurate value 119.95334291146037, computed as a double.

On X11, you would need to use slightly different API to get the value (see the answer here). Windows and macOS can also give you similar float/double value.

If you want perfect frame pacing on a non-vsync system, you have to do a bunch of maths/stats on frame times, but for that, you need the accurate value of the refresh rate, not the rounded int value.

This is why SDL3 moved from int to float:

typedef struct SDL_DisplayMode
{
    SDL_DisplayID displayID;        /**< the display this mode is associated with */
    SDL_PixelFormat format;         /**< pixel format */
    int w;                          /**< width */
    int h;                          /**< height */
    float pixel_density;            /**< scale converting size to pixels (e.g. a 1920x1080 mode with 2.0 scale would have 3840x2160 pixels) */
    float refresh_rate;             /**< refresh rate (or 0.0f for unspecified) */
    int refresh_rate_numerator;     /**< precise refresh rate numerator (or 0 for unspecified) */
    int refresh_rate_denominator;   /**< precise refresh rate denominator */

    SDL_DisplayModeData *internal;  /**< Private */

} SDL_DisplayMode;

Maybe float gives enough precision? I don´t know.

This would be a API breaking change, so can wait. I maintain my own fork so I'm not stuck.

[ColleagueRiley]

Definitionally seems like an oversight. RGFW 1.8.0 is currently not accepting new features, it's in a testing stage. This should be added in 1.8.5.

[vtlmks]

One idea would be to have a frametime instead of refresh rate? using an uint64_t for number of nanoseconds between frames.

[ColleagueRiley]

Most systems will provide the monitor's refresh rate directly, so it's better to go based on that.

[EimaKve]

One idea would be to have a frametime instead of refresh rate? using an uint64_t for number of nanoseconds between frames.

what's a "frame time" in relation to a monitor?

[ColleagueRiley]

I don't think that suggestion makes much sense in relation to a monitor's refresh rate.

I don't think limiting the FPS based on a target frame time is a good idea, but even if it was the target frame time would need to be calculated based on the monitor's refresh rate.

[ColleagueRiley]

@mpalomas I'm not sure how practical this would be. The X11 function XRRConfigCurrentRate you mentioned outputs a short, as seen in the example you mentioned and Windows does not give us a floating point freshrate either. The only OS that easily gives us a floating point is OSX.

I ran a quick test with my monitor with a floating point freshrate with SDL and SDL rounded my refreshrate from 59.9 to 60.