From what I can tell reading through the source, it would have been bottlenecked by the CPU instead of the GPU. Thus whether you used VAs, VBOs or IMs it probably wouldn't make any significant difference.
It tried: IM > VA > VBO.
Your usage of the word "Batch" to describe the class containing the data for a single drawable is also kind of misleading. They weren't really batched data and so could not profit from batching at all.
Your idea of uploading data into a single buffer and drawing all at once at the end was good. HOWEVER, if you only draw the data one object at a time they will be, as you saw, hardly any better than VAs or even IM.
I was accumulating vertices inside a sf::Batch until one state changed, so if drawing many sprites using the same texture, for example, I would end up drawing a single big chunk of geometry at the end.
Because you changed SFML a lot since then and cache states more effectively now and even use VAs as the primary drawing method, it would be nice to see how that old concept would fare in the current implementation.
I'll probably give it another try, yes.
And I'm curious, were these problems you speak of bugs/glitches or the flexibility/limitation kind of problems? I couldn't find any reports of problems related to the old drawing method while searching through those old threads.
I can't remember
1. Some way to identify/compare fonts among each other (name of the face or something).
In most use cases this will be useless: one can store the name when it loads the font, or use the sf::Font pointer as an identifier. Problems arise when you write a middleware, like SFGUI, and have no control on font instances. What kind of other use case could it be useful for?
2. Some way to tell SFML to wipe it's vertex cache.
I know that it's not very efficient, but currently SFML is not designed to be mixed with OpenGL this way. One must call Push/Pop/ResetGLStates in order to avoid messing up internal states. Supporting custom OpenGL commands in the middle of SFML rendering would require more work on my side, and probably a slightly different public API.
Out of curiosity, is it really a performance killer to call ResetGLStates once per frame?
3. Since you allow asking for a depth/stencil buffer, it would be nice to be able to clear those with RenderTarget::Clear() too instead of just the color. Now users have to resort to calling glClear() themselves which is horribly expensive.
I understand. However it would be weird to have something related to the depth buffer in the graphics module, which doesn't deal with depth at all.
4*. A standard benchmark spec that encompasses all areas of SFML to use as a performance measurement tool while trying to optimize SFML. This is one of those crucial things that I and others would need to know to experiment with making SFML faster.
I could show my own test app as a starting point, and maybe we could improve it together?
