Yeah, it’s guaranteed to persist between draw calls, because it’s implemented
as a normal texture… that you can render onto.? That’s exactly the reason why
I set up the feature that way: they’re incredibly useful for compositing.
Mason________________________________
From: Sik the hedgehog <sik.the.hedgehog at gmail.com>
To: sdl at lists.libsdl.org
Sent: Tuesday, June 18, 2013 11:57 PM
Subject: Re: [SDL] SDL_RenderPresent and ‘persistency’ of graphics
No, it isn’t, in fact it’s pretty much undefined. This is not
something over which SDL has much control (at least not without a
severe performance hit), this is how GPU APIs (OpenGL and Direct3D)
work. You simply can’t tell if the OS decided to draw over whatever
was the front buffer.
However, there’s SDL_SetRenderTarget which lets you draw to a texture
(which I imagine will be guaranteed to be stable since the OS won’t
draw over it). You could probably fake the behavior you want by
drawing to a texture then at the end draw the texture on screen (all
of this would be done GPU-side, as a bonus).
2013/6/17, mfidler <mirek.fidler at gmail.com>:
I am trying to use SDL2.0 as GUI backend and to make things optimal, I would
like to have one clarification about SDL_RenderPresent - is it guaranteed
that graphics drawn before SDL_RenderPresent is the initial status for
subsequent drawing?
I mean, consider:
erase background
draw "Hello"
SDL_RenderPresent
draw "? ? ? ? world"
SDL_RenderPresent
Is it guaranteed that I now see “Hello world” on the screen?
(I have tested in X11, it looks that it works just fine, but I am afraid
that in some hosts SDL_RenderPresent might be implemented as some sort of
"buffer swap", which would mean that each frame has to be rendered
completely - not quite optimal for GUI use, where you often need to repaint
only small part of window).
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Are you speaking about SetRenderTarget above, or replying (in disagreement with Sik) to my original post?