Saving memory bandwidth by not calling glTexCoordPointer()

[hobby]

For an application that makes heavy use of vector graphics that is rendered in batches with sf::VertexArray, using textures only infrequently for drawing text, performance might be improved by having RenderTarget::draw() not call glTexCoordPointer() in case that no texture nor shader is active, disabling the texture coords client state if needed.

Could you consider such an option for SFML?
Alternatively, how would you suggest to get a similar behavior with SFML without modifying its source code?

[Laurent]

So it would be

if (!states.texture && !states.shader)
    glTexCoords(...);
else
    glDisableClientState(GL_TEXTURE_COORD_ARRAY);

?

We just need to make sure that GL_TEXTURE_COORD_ARRAY is managed properly, and of course check that it is indeed more optimized in the general case, but that seems doable.

[hobby]

Yes, that would be great!

Is it safe to assume that glDisableClientState() will be no slower than glTexCoordPointer()?

A potential worst-case scenario may be to perform a sequence of drawing calls with a small number of vertices, alternating between using and not using texture/shader. In that case, glTexCoordPointer() will be replaced by two calls (glEnable/DisableClientState), though. I guess that scenarios of this sort are not too common among performance-aware users of SFML anyway.

[hobby]

This optimization has indeed increased performance in my case.

The implementation (including state management) can be seen in https://github.com/hobby8/SFML/commit/4c68bf1bb62bd5d6210b60f341fa827e9d7c7ec3

Should I open a pull request?

[Laurent]

Should I open a pull request?

I'd say yes. Thanks for working on it

[hobby]

You're welcome, you've made it very easy to contribute. Created #1015.

Do you have benchmark programs for testing performance-related features?

[Laurent]

Do you have benchmark programs for testing performance-related features?

No. In a perfect world we would have ready-to-run programs that test the most common cases, as well as unit tests, but we still have nothing