Ok and in other case the back buffer also has what's currently on the front buffer and we can paint it partly over and then swap?

Related to that do you know why we present() in prepareRenderingFrame (in DRM backend as well) and not after the actual paint in endRenderingFrame?

Ok and in other case the back buffer also has what's currently on the front buffer and we can paint it partly over and then swap?

No, but the buffer age extension makes it possible to query the number of frames that have elapsed since the current back buffer was the front buffer. Based on that we can calculate how much we need to repaint to bring it up-to-date.

See void OpenGLBackend::addToDamageHistory(const QRegion &region) and QRegion OpenGLBackend::accumulatedDamageHistory(int bufferAge) const

Related to that do you know why we present() in prepareRenderingFrame (in DRM backend as well) and not after the actual paint in endRenderingFrame?

This code was written based on the idea that SwapBuffers() blocks until the swap is complete, which also means that it blocks until the next vblank.

The logic can be illustrated with the following pseudo code:

while (true) {
    SwapBuffers(); // For the previous frame
    renderTimer.start();
    paint();
    glFlush();

    // Sleep until just before the next vblank
    int timeSinceLastVBlank = renderTimer.elapsed();
    sleep(vblankInterval - timeSinceLastVBlank);
}

In practice we don't call sleep of course; instead we start the composite timer with the timeout set to just before the next vblank, and return to the event loop.

But the only driver where SwapBuffers() behaves like this is the NVIDIA driver, and its not the default behavior. It's enabled by setting __GL_MaxFramesAllowed to 1 before initializing OpenGL.

The reason the next frame is rendered immediately after the buffer swap instead of doing it as late as possible is to avoid missing the vblank when there is a sudden increase in render time. Also if we miss the vblank by one millisecond, the main thread will be blocked in SwapBuffers for 15 milliseconds, which is less than ideal.

But there's obviously a trade-off here between smoothness and latency.

Related to that do you know why we present() in prepareRenderingFrame (in DRM backend as well)

Correction: in DRM backend we actually present on endRenderingFrame!