Vsync

[chipmusic]

Hi, thank you so much for the work on this crate. Love how simple and efficient it is.

The only one thing keeping me from using it right now is that the frame timing seems to be based on thread::sleep, which usually gives a very uneven result and can vary per platform a lot. This is exactly what I'm observing, the frame timing is very uneven from frame to frame, leading to a jerky motion.

Is there a way to wait for Vsync, instead of limiting the frame rate with set_target_fps?

[emoon]

Hi, Thanks :)

Currently there is no way to vsync no so that would have to be implemented on all the platforms which I unfortunately currently don't have time to do.

If you are willing to help out a bit with this (like looking into how it can be done for various platforms) I might be able to do it if it's not too much work to implement it.

[chipmusic]

Thank you, no problem!

I've handled similar situations using frame skip if the elapsed time is too short. May Still stutter occasionally via a dropped frame here and there, but much less visibly than with thread::sleep and the timing tolerance can be configured per platform. Looks like this:

// Will skip frames and wait a small minimum time if running too fast.
// May still stutter, but less than sleeping the entire desired frame time.
const TARGET_FPS:Option<f32> = Some(60.0);
const TARGET_FPS_TOLERANCE:f32 = 1.05;
const MINIMUM_WAIT_MS:u64 = 1;

    // (...)
    let mut frame_time = Instant::now();
    // (...)
    
    // At the very beginning of the update loop
    let update_frame = if let Some(fps) = TARGET_FPS {
        if frame_time.elapsed() < Duration::from_secs_f32(1.0 / (fps * TARGET_FPS_TOLERANCE)) {
            false
        } else {
            frame_time = Instant::now();
            true
        }
    } else {
        frame_time = Instant::now();
        true
    };
    
    // At the end of the update loop
    if update_frame {
        // Code that actually updates, renders and presents the render_target texture
    } else {
        std::thread::sleep(Duration::from_millis(MINIMUM_WAIT_MS));
    }

Instead of waiting the entire frame time, there's a small sleep to keep CPU from maxing out while waiting that may need to be adjusted per platform. Those values work well on my laptop both plugged (120 Hz display) and unplugged (60Hz). I'm using milliseconds since some platforms may not have higher precision available (not sure if that's still a thing!).

If the tolerance is too low (i.e. 1.0) it may wait too long to update, so it's a delicate balance.

This method also seems to play well with Vsync in case it is forced by the driver.

[chipmusic]

Actually, it just occurred to me I could try that approach "on top" of minifb, setting the target fps to zero and managing the frame update timing on my own end with several small sleep increments, but it didn't work and I can't figure it out.

It's like there's something still introducing a delay that messes up the timing.