SFML community forums

Help => Graphics => Topic started by: oomek on April 26, 2018, 02:53:20 pm

Title: setView() performance penalty
Post by: oomek on April 26, 2018, 02:53:20 pm

Is performance penalty signifficant if setView() is called before every draw() call?
I have a list of drawable class instances and each has defined to which view it belongs. I would like to keep the drawing order that way. Does the performance change significantly If I’ll do it that way?

Title: Re: setView() performance penalty
Post by: Laurent on April 26, 2018, 03:06:24 pm

Performances always depend on many things, other than the code that gets executed, especially the user environment. So you'd better benchmark it if you want to know for sure.

And if you look at the code, it is quite simple and you can easily see what happens when you call setView.

Title: Re: setView() performance penalty
Post by: oomek on April 26, 2018, 03:37:01 pm

I did just this comment made me a little worried.
https://github.com/SFML/SFML/blob/0adde249ec9fd2012c53b5f57f71989ffd88d16f/src/SFML/Graphics/RenderTarget.cpp#L730

Title: Re: setView() performance penalty
Post by: Laurent on April 26, 2018, 08:04:30 pm

glViewport(viewport.left, top, viewport.width, viewport.height);
glMatrixMode(GL_PROJECTION);
glLoadMatrixf(m_view.getTransform().getMatrix());
glMatrixMode(GL_MODELVIEW);

This is basically what gets called when drawing, if setView was called. Is it expensive? It depends on your graphics driver. Is it impacting performances too much? Only you can know ;)

Title: Re: setView() performance penalty
Post by: oomek on April 26, 2018, 08:47:55 pm

Fair enough Laurent.
Since this project is multiplatform and works even o Raspberry-PI I wouldn’t like to rush the choices and degrade the performance before making tests. No matter how I despise RPI I’m being forced to buy one :)

Title: Re: setView() performance penalty
Post by: Chaia* on May 01, 2018, 11:52:17 am

Generally for optimal performance you should sort your drawcalls by state changes. Of course, the most expensive ones should be changed the least often. I.e. Context switches (=rendertexture/window), framebuffer (=rendertexture), shader (but this is as far as I know useless with SFML, as shaders are always set again), textures, vertex buffers (if you use any) and then all the small stuff just as matrices, uniforms and so on. In SFML you further have to sort by "depth", i.e. the order you want things to be drawn. However, the order has only to be considered if the two entities somehow overlap.

Especially when you have a lot of overlapping entities, this can become very complex so you should first profile your application to see if there is a need for improvement here. But for optimal performance this is one of the ways to go there.