setView() performance penalty

[oomek]

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?

[Laurent]

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.

[oomek]

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

[Laurent]

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

[oomek]

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

[Chaia*]

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.