sf::VertexBuffer::update() memory reallocation

[trider]

Was going to open an issue on GitHub, but then thought maybe I'm missing something here.
https://github.com/SFML/SFML/blob/master/src/SFML/Graphics/VertexBuffer.cpp line 191:

    // Check if we need to resize or orphan the buffer
    if (vertexCount >= m_size)
    {
        glCheck(GLEXT_glBufferData(GLEXT_GL_ARRAY_BUFFER, static_cast<GLsizeiptrARB>(sizeof(Vertex) * vertexCount), nullptr, VertexBufferImpl::usageToGlEnum(m_usage)));

        m_size = vertexCount;
    }

The code means that when vertexCount == m_size we allocate a new buffer instead of updating the old one, and then assign m_size the same value it had before. This, of course, has performance implications, so the question is - why?

[binary1248]

https://www.khronos.org/opengl/wiki/Buffer_Object_Streaming

[trider]

Shame on me.

Then another question regarding re-specification - the doc you linked says:

Since allocating storage is (likely) faster than the implicit synchronization ... it is likely that the GL driver will not be doing any allocation ... (though of course this isn't guaranteed)

However, https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glBufferSubData.xhtml seemingly contradicts this statement:

When replacing the entire data store, consider using glBufferSubData rather than completely recreating the data store with glBufferData. This avoids the cost of reallocating the data store.

So, should I switch to raw glBufferSubData calls when using large buffers? And by large I mean rendering all game objects (apart from GUI) in one single buffer.

[binary1248]

Performance characteristics change from vendor to vendor, GPU to GPU, OS to OS and driver version to driver version. The best you can do is measure the performance of each approach, pick what currently suits you best and hope it stays that way. Welcome to the OpenGL club.