SDL_Renderer: Reducing the number of render calls |
SDL_Renderer: Reducing the number of render calls |
Jonny D
|
This general idea has been discussed and it is good. Â It does take a bit of work, though, as SDL would have to take care to flush the VBO whenever a state change is issued.
The SDL rendering subsystem and API is very good for porting old projects, but if you really need more performance or flexibility at the moment, either look to OpenGL directly or SDL_gpu, which wraps OpenGL in a 2D API with this optimization already implemented. Jonny D On Fri, Aug 8, 2014 at 1:39 AM, Tero Lindeman wrote:
|
|||||||||||||
|
SDL_Renderer: Reducing the number of render calls |
kometbomb
|
|
|||||||||||||||
|
SDL_Renderer: Reducing the number of render calls |
Sik
|
2014-08-08 13:09 GMT-03:00, Tero Lindeman:
Good point, though honestly I doubt it's commonly used, it's likely most programs just call SDL_RenderFillRect several times. Same deal with SDL_RenderDrawRect(s). There's also SDL_RenderDrawLines, where the same situation applies. However, that one may be more worth looking into, because rendering multiple lines together in a single batch is actually pretty useful (e.g. if you're rendering a wireframe or a grid or something like that). How bad is this, anyway? They barely cause a state change, in contrast with SDL_RenderCopy, which has a rather heavy state change (changing the texture has a much more severe penalty). You'll still need a large amount of blits to actually cause slow down, but even then. _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
SDL_Renderer: Reducing the number of render calls |
kometbomb
|
|
|||||||||||||||
|
SDL_Renderer: Reducing the number of render calls |
Jared Maddox
Guest
|
I spent so long looking for the link, I accidentally deleted my workspace file.
There have been suggetsions of this before, and I've spent the time to dig up the most recent instance that I actually remember. Here's the month: http://lists.libsdl.org/pipermail/sdl-libsdl.org/2013-April/date.html And here's the first message, which was honestly not very informative: http://lists.libsdl.org/pipermail/sdl-libsdl.org/2013-April/653855.html And here's my suggestion for an algorithm: http://lists.libsdl.org/pipermail/sdl-libsdl.org/2013-April/088109.html tl;dr: If you want to buffer, then you probably want to batch, and for SDL's Renderer API that means that you need to be careful not to accidentally perform render B to a point when render A was supposed to be done to that point first. This can be handled by grouping renders into host nodes, and simply pushing a new node every time that you have a "rendering collision". For some reason I was thinking that a tree implementation was needed, so if you want a tree for it I can provide you with one that I've been needing to write tests for (there were objections to involving an external library). _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
krux
|
I would love to have a SDL_RenderCopies that takes an array of source rects an array of target rects, but only one src texture, so that I can build up my own texture atlas. And don't underestimate the performance increase here. On modern hardware there is practically no difference in rendering 200 triangles or 2 triangles when you draw them in one single draw call. So the potential here is at least a factor of 100 if it is done right. And please no tree structured buffering. Don't declare the programmer stuped who can't properly setup batched rendering.
|
|||||||||||
|
kometbomb
|
Thanks for the links to the earlier discussions.
IMHO a tree-based approach would be overkill compared to a very simple "batch polys until the texture/blending mode changes or the user wants to read pixel data" style batching, considering the worst case performance would be close to what it is now. SDL_RenderCopies with a single texture would be a nice solution that sits between the two extremes. I think I'll experiment with this and post results. |
|||||||||||
|
krux
|
nice to have somebody who is willing to spend some time here. I also spent some time thinking about how this could be done right. If a geometry shader is available and the gpu can to integers, then all vertex creation could be done in the geometry shader, passing only the raw arrays of rectangles. But sadly that's not an option for opengles |
|||||||||||||
|
SDL_Renderer: Reducing the number of render calls |
Jeffrey Carpenter
Guest
|
If you use a function that uses SDL_RenderLine for dithered, linear gradient filled backgrounds, and then use it for three (roughly) 320x240 sized widgets (720ish +/- draw calls per frame if I remember right), you can easily start seeing performance issues. A (roughly) ~15..30fps+ diff can be seen. This doesn't matter much to me on my Macbook (Intel Graphics 3000 with plenty of fps to spare), but certainly matters a great deal on my older single core AMD64 windev box (Geforce 6200), where I've seen fps drop as low as 4fps, and unable to peak greater than 10fps. I certainly have slight concern with the performance of the code under iOS, but unfortunately, that test won't see the light of day for some time. Admittedly, I haven't tried very hard at optimizing the function, nor are any of these tests done on a release build, so you might have to take my comment with a grain of salt? :-) P.S. Sorry for my brevity, I'm emailing from my phone. Cheers!
SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||
|
SDL_Renderer: Reducing the number of render calls |
Sam Lantinga
|
Don't use SDL_RenderLine for gradient backgrounds. Instead you should have a pre-filled gradient texture. If you want it dynamically a single color you can make it greyscale and use texture color mod to color it. If you want it multi-colored dynamically you could use a render target and render lines into that and then use that as your gradient. The texture doesn't need to be very big, either.
This will save you a huge amount of performance. The SDL line and point API functions are not designed for massive numbers of calls, just some additional work to fill in gaps between textures or do a little background decoration. If you need something like a particle system or vector art, you should probably use OpenGL directly. Cheers! On Wed, Aug 13, 2014 at 2:31 PM, Jeffrey Carpenter wrote:
|
|||||||||||||||||||
|
SDL_Renderer: Reducing the number of render calls |
Jeffrey Carpenter
Guest
|
On 2014/08/ 14, at 0:57, Sam Lantinga wrote:
Thanks a lot for the suggestions -- it helps confirm what I had in mind for optimization once the time rolls around for it (I have the luxury of simply ignoring the issue for the time being). It is nice to know that I was thinking in the right direction :-) During the time that I discovered the performance issue (a few months ago), I experimented with one-time rendering the gradient fill to a rendering target and then rendering from that, and sure enough, the performance improved dramatically for me. At this time, the thought occurred to me that I could probably just use a regular texture for this. I hadn't thought of using a greyscale texture -- interesting idea, I might just have to give it a shot... texture color modulation works wonders for bitmap fonts....
Indeed, the API has been wonderful for my other needs! (mostly as a bits and pieces decorator). Cheers, Jeffrey Carpenter
_______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||||||||
|