I’m experimenting with SDL for a personal multimedia project and have been testing different rendering approaches for frame previews.
One challenge I’m running into is timeline scrubbing. When users drag quickly across the timeline, rendering every frame can become expensive, especially with higher-resolution media. This is similar to the behavior found in many windows video edit applications where preview responsiveness is more important than displaying every intermediate frame.
For those who have implemented something similar with SDL:
Do you typically skip frames during rapid scrubbing?
Is texture caching usually the preferred approach?
Are there any SDL-specific techniques that help maintain responsiveness while keeping memory usage reasonable?
I’m interested in hearing what approaches have worked well in real-world projects.
Yes. I invariably run with SDL_RENDERER_PRESENTVSYNC enabled so - based on the time at which the next frame will be presented (which of course is impossible to determine accurately, because it’s in the future, but can be estimated) - I’ll calculate where and in what state anything moving/changing should be.
In the case of a scrolling video timeline that may certainly mean that intermediate frames aren’t rendered at all. This is the same as any kind of scrolling; if you’re scrolling quickly through a document some text may never be rendered because it has moved from below the display window to above it in one frame period.
One hint for better responsiveness:
In the event loop, do not do any video/scrubbing/preview processing inside of the mouse motion event handler. Just capture the mouse position and process the last position outside of the event loop. Many gaming-computer-mice out there are capable of producing thousands of events per second, even a standard mouse is likely outputting multiple events per frame when the mouse is moving. You only really need to process the last motion-position per frame.
I also place the mouse motion event case top-most in the event handler in the hope of having it process quickly each loop. (I’ve seen claims that some compilers are able to optimize this step for you, but there’s no harm in doing so in the code itself.)