SDL2: copy SDL_Texture to SDL_Surface?

Hi, this is a question for SDL2 gurus.

The data transfer from a SDL_Surface to SDL_Texture is covered very well, but not the other way around. I need this to create floating windows and menu’s. In SDL1.2 you could save the pixels from the screen in a temporary SDL_Surface, and re-blit them afterwards. If this is not possible any more, then I am forced to fully redraw all widgets that are (partly) covered by the floating window, also if it is moved. This is how Android and also Qt operate, and I think it’s stupid. By the way: if I would abandon hardware acceleration, then there would be no problem, but the fun would be gone.

wboe

The data transfer from a SDL_Surface to SDL_Texture is covered very well,
but not the other way around. I need this to create floating windows and
menu’s. In SDL1.2 you could save the pixels from the screen in a temporary
SDL_Surface, and re-blit them afterwards. If

If you work with a 3d hardware acceleration you always redraw the whole
screen (also if you renderer a 2d program), so keeping some sort of
backbuffer has no use.

Android/QT/iOS/… always do this, also to draw widgets/views and it’s not
stupid, it’s faster :)–
Ing. Gabriele Greco, DARTS Engineering
Tel: +39-0100980150 Fax: +39-0100980184
s-mail: Piazza Della Vittoria 9/3 - 16121 GENOVA (ITALY)

Hi Gabriele,

Apparently we live in different worlds javascript!

If you work with a 3d hardware acceleration you always redraw the whole screen (also if you renderer a 2d program), so keeping some sort of backbuffer has no use.

Suppose you want to make an application with a lot of sliders, menu’s etc and also an animated picture. Then it would be a bad design if you recalculate the drawing of all those widgets at each frame. SDL2 offers a hybrid solution: draw and store widgets at a low speed, and also render animated pictures hardware-accelerated. That’s what I want to do. All this is available, except the possibility to create floating windows.

wboe