I thought that RenderPresent would just function to display the rendering done by other functions, like RenderCopy, to the screen, but it appears that the amount of time it takes is heavily related to how much drawing was done to the renderer. What does RenderPresent actually cause to happen? I’d presume you’d have to factor in the time RenderPresent takes so that it finishes before / at the time you want to show your frame, rather than starting it at that time?
SDL2 Renderer uses batched rendering, so the actual draw commands won’t be dispatched until either a state change necessitates it, or SDL_RenderPresent() is called. Functions like SDL_RenderCopy() just queue up stuff to be drawn later.
1 Like
Thank you, that explains it!
Then, without vsync, is it fine to RenderPresent anywhen before the frame will be displayed (I assume RenderPresent is non-blocking without vsync)? Can it result in screen taring if I call it multiple times before the screen refreshes?
And with vsync, is the call to RenderPresent cpu efficient, or more equivalent to a busy wait?
I don’t understand why you would want to do this. I doubt the side effects are well defined since there are multiple backends and even multiple implementations of some of them (OpenGL).
It sounds like maybe you want to just use render targets to render to a texture instead of the screen? SDL_RenderPresent is just for drawing to the screen and there is not a point (that I can think of) for doing that multiple times a frame. If you just want the render commands flushed so that you can do your own rendering outside of SDL_Renderer then just call SDL_RenderFlush
1 Like
was just something that I was wondering about in case it would come in handy at some point. While it does seem unlikely to be useful, I mainly wanted to get a good understanding of what the API does(n’t) allow. I’m very new to any sort of game/application dev and have mainly been using the wiki to try and learn the API. Sorry for the somewhat stupid questions.
Only call SDL_RenderPresent() when you’re ready to put a finished frame on the screen.
And yes, without vsync there can be visible tearing.
As to what it’s doing behind the scenes to get vsync, that depends on both the API and the platform. On Windows and Macs, at least, it uses the underlying OS mechanism for synching to the display refresh.