Palettized RGB Surface in SDL 2 much slower than in SDL 1 |
sanitowi
|
Hm, if I create the renderer with the
SDL_RENDERER_SOFTWARE flag I get the same result (speed) as with SDL 1. As mentioned i am new to graphics programming. Can someone explain this behavior to me? Maybe the graphics card wihch the hardware renderer uses (correct me if I'm wrong) is so slow? ... it's an intel hd2000 (i3-2100) ... |
|||||||||||
|
krux
|
The problem is not easy to explain, but indexed colors are not a major focus of modern GPUs, especially the chea ones. Always use 32 bit color, and you do not have this problem. Indexed colors give you an advantage in software rendering though, because the throughput of data from the program to the GPU is reduced.
|
|||||||||||
|
Palettized RGB Surface in SDL 2 much slower than in SDL 1 |
Driedfruit
Guest
|
On Sat, 24 Jan 2015 02:02:17 +0000
"sanitowi" wrote:
This is because software renderer uses SDL_Surfaces internally, so the behavior (and performance) becomes similar to SDL1.2 blitting. As for the GPU slow-down, I don't see anything wrong with your code. Maybe someone with a keener eye can spot something. Have you tried creating the texture *without* the SDL_TEXTUREACCESS_STREAMING flag, and/or *not* using Lock/Unlock functions? What is your renderer backend? -- driedfruit _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
Magnet
|
I'll give a few tips since i've worked on this myself quite a bit for the speed.
1. Locking and Unlocking the texture here like so doesn't do anything:
1. Create the Surface then update the pixel format once, then you don't need to convert it every time you blit and update. Try something like this:
Let me know how it works out for you. I use this myself and it's very fast when done in this order. |
|||||||||||||||
|
Magnet
|
And a small tip, if your loading an image into the surface. Then convert the surface once after the image is loaded.
|
|||||||||||
|
sanitowi
|
Thanks for your detailed answers!
I will look at them and try some suggestions ... the next days. ... btw I am not loading bitmaps, I just want to do some pixel manipulations in software and then "blit" to screen, e.g. starfields, palette effects ect. .. the old demo stuff |
|||||||||||
|
sanitowi
|
@Magnet I looked at your suggested code. I will try that, but two questions. I want a 8bit palettized surface as video_buffer, will your code still work then? I figured out for me, in this case I need to convert from 8bit to 32bit everytime befor I update the texture. If it is not needed, the I wouldn'T need the helper_surface. Am I wrong?
What is rect and &pick here? |
|||||||||||||||
|
Magnet
|
That is correct. Keep your 8 bit If you need it. .. you might not need to convert it if you bitl to a converted surface already. You'll have to Play with that Some.. just the main thing is to convert it before texture update and try to limit conversion if you can to save speed. Oops pick is suppose to be rect.. typo.. and that copies the specific dimensions of surface.. null works too. I like putting in the size though. |
|||||||||||||||||
|