This crate supports on getting the timing right for sdl2 applications. Timing is important to avoid lag (too slow rate) or high cpu load (too high rate). sdl2 offers the possibility to enable vsync synchronization, which is best solution for responsiveness at lowes cpu load.
Example to enable vsync with CanvasBuilder:
let mut canvas = sdl2::render::CanvasBuilder::new(window) .accelerated() .present_vsync() .build()?;
So why need this crate ?
At least on the macbook air without external monitor, the vsync just is not in use. So depending on vsync for appropriate rate will let the main loop spin at max. rate and creates too high load. With external monitor attached, vsync works. Consequently a solution is needed to either rely on vsync or use delays as fallback.
Querying the window.displayMode() for the current framerate, is not reliable. At least on one linux machine 60Hz has been reported, while operating a 4K display at 41Hz.
Even relying on vsync is tricky. First canvas.clear() and canvas.present() can wait for vsync to occur. Second for moving element calculation, it is good to know the time till the next frame for proper display position.
This crate provides a single struct Sdl2Timing, which offers:
- Call canvas present and canvas clear
- Timing measurement inside the main loop
- Output of timing data for development
- Info about real framerate,...
- Remaining time to next frame