Messages

1

Graphics / Re: sf::VertexBuffer::update() memory reallocation

« on: January 11, 2022, 04:45:32 am »

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.

2

Graphics / sf::VertexBuffer::update() memory reallocation

« on: January 11, 2022, 03:22:32 am »

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?