Skip to content

Fix FFGLFBO::Release leaking the color texture - #104

Open
stoatworks-labs wants to merge 1 commit into
resolume:masterfrom
stoatworks-labs:fix/fbo-color-texture-leak
Open

Fix FFGLFBO::Release leaking the color texture#104
stoatworks-labs wants to merge 1 commit into
resolume:masterfrom
stoatworks-labs:fix/fbo-color-texture-leak

Conversation

@stoatworks-labs

Copy link
Copy Markdown

FFGLFBO::Release() has two consecutive blocks guarded on depthBufferID:

if( depthBufferID != 0 )
{
    glDeleteRenderbuffers( 1, &depthBufferID );
    depthBufferID = 0;
}

if( depthBufferID != 0 )
{
    glDeleteTextures( 1, &depthBufferID );
    depthBufferID = 0;
}

The first block zeroes depthBufferID, so the second is unreachable. It was
plainly meant to test and delete colorTextureID, which is therefore never
deleted — every FFGLFBO release leaks one texture.

That matters in practice because Initialise() calls Release() on its own
failure paths, and plugins that keep FBOs for intermediate passes release and
re-initialise them on every resolution change. The leaked textures are
full-size render targets, so it adds up over a session.

The fix is the three-line change to the second condition. No behaviour changes
beyond the texture now being deleted; if colorTextureID is already 0 the block
is skipped exactly as before.

🤖 Generated with Claude Code

The second block in Release tested depthBufferID, which the preceding
block had already set to 0, so it never ran and colorTextureID was never
deleted. Every FFGLFBO release leaked one texture.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant