Vertical sync (VSync / frame-limiting)

[LoganDark]

Is it possible to perform vertical sync with this library? i.e. deliver a new frame to the screen every monitor refresh, but not any more frequently? It doesn't seem like the library does anything special about it, but I'm not 100% sure how this should work (is it the responsibility of the user to figure out the refresh rate and stuff?).

[i509VCB]

Wayland should be able to implement this with frame callbacks.

[ids1024]

This would probably be better implemented in winit as an event sent to the event loop (rust-windowing/winit#2412). We could make set_buffer block on the frame callback, which Mesa's eglSwapBuffers does when eglSwapInterval isn't zero. But that blocks indefinitely on an occluded window, and should at most be an option.

[qwertzui11]

On wayland I had success with window.pre_present_notify();. As documented in request_redraw().

[kryptan]

On Windows I found that you can call DwmFlush in about_to_wait to limit framerate:

    fn about_to_wait(&mut self, _event_loop: &ActiveEventLoop) {
        #[cfg(windows)]
        unsafe {
            windows_sys::Win32::Graphics::Dwm::DwmFlush();
        }
    }

Not sure if it's the best way but it works.

[madsmtm]

Assume for the moment that Winit consistently implemented some sort of rate-limiting window.request_redraw() in WindowEvent::RedrawRequested.

What's the expected behaviour for Softbuffer when the user is not rendering at the display refresh rate?

Asked differently, what's the expected behaviour of the following:

WindowEvent::RedrawRequested => {
    surface.buffer_mut().unwrap().present().unwrap();
    surface.buffer_mut().unwrap().present().unwrap();
    surface.buffer_mut().unwrap().present().unwrap();
    window.request_redraw();
}

If we assume a double-buffered implementation, then the first buffer_mut should get the back buffer, the first present should commit it to the display server and swap the buffers, but what about the second and third buffer_mut?

Should it block, waiting for the back buffer to stop being used by the display server? It sounds like the only option IIUC, but aren't we re-implementing frame-limiting then? Or perhaps we aren't, if RedrawRequested is properly scheduled to only be triggered once every frame, and the user properly only requests a single buffer each frame, then there should never be a point where the back buffer is in use by the display server, right? (Should we warn, then, if it is?)

If we don't want blocking, then the only other option is triple-buffering (or creating a new buffer every frame), is it not? With one surface being actively read by the display server, another being commited to the display server (standing ready, but not yet used), and the third being rendered into (with the second and third being swapped between if rendering too fast).

I guess a similar question is: What should happen if rendering continuously off the main thread? E.g. if you do:

std::thread::spawn(move || {
    loop {
        surface.buffer_mut().unwrap().present().unwrap();
    }
});

What would we like to happen here? I suspect that blocking is desirable for this use-case. But it hints that we should perhaps expose buffer_mut_timeout(dur: Duration) too, to allow doing other stuff on that thread if frame callbacks happen to be far apart?

---

I'm asking because using CALayer::setContents on macOS/iOS does not seem to expose any way to know when the layer is finished using the old surface, other than waiting for the next frame with CVDisplayLink/CADisplayLink. And thus, we need to make a conscious decision on how to handle this (do we use double buffering and wait on a condition variable set in the frame callback, or do we use triple buffering and signal the state with atomics).

[dhardy]

wgpu has PresentMode for a reason: there isn't a one-size-fits-all solution. Using that terminology,

• Fifo would block surface.buffer_mut() until the next back buffer is available
• Immediate would swap buffers as soon as present is called
• Mailbox (IIUC) uses triple buffering but replaces the queued frame (if any) when present is called

Frame-limiting can also be done from another angle: delaying WindowEvent::RedrawRequested. This potentially allows for a more responsive app. For example with Kas GUI, using wgpu's PresentMode::Fifo I find that drag-resizing a window with the mouse can lag; using PresentMode::Immediate or PresentMode::Mailbox fixes this but results in continual drawing above the target frame rate; the correct fix would be to estimate when to issue RedrawRequested in order to hit the monitor's frame rate (which is a winit issue not softbuffer).

[madsmtm]

there isn't a one-size-fits-all solution

Ah, I was fearing that, thanks a lot for the pointer! Do you know of any good literature on these concepts and/or further prior art? I see that the SDL provides Fifo, Immediate and Adaptive (IIUC).

Immediate would swap buffers as soon as present is called

I was under the impression that it would violate memory safety, since it'd be a race condition for the CPU to write while the GPU / display driver / whatever reads.

But then I realized, it's not equivalent to two threads racing, it's something completely different, we're talking about buffers that are synchronized by the OS / hardware, and operating over at least a process boundary. And besides, the buffer should still be internally consistent for the CPU, since the GPU never writes to it, so the biggest issue is the GPU reading partial data, which is a well-known problem: tearing.

[dhardy]

No, sorry. (I have read a couple of interesting articles in the past, but less on platform specific integration, and I am unable to find them now.)

[MarijnS95]

(Without reading back the entire thread, just seeing the last WGPU mention): they have a bunch of PRs open that aim to change/extend PresentMode again 😅

[madsmtm]

(Without reading back the entire thread, just seeing the last WGPU mention): they have a bunch of PRs open that aim to change/extend PresentMode again 😅

Uhh, where?