Skip to content

Comments

[ALL] Fix color picker frame not regenerating the preview texture after being closed#1781

Open
SanyaSho wants to merge 4 commits intoValveSoftware:masterfrom
SanyaSho:fix/decremented-texture-handle-fix
Open

[ALL] Fix color picker frame not regenerating the preview texture after being closed#1781
SanyaSho wants to merge 4 commits intoValveSoftware:masterfrom
SanyaSho:fix/decremented-texture-handle-fix

Conversation

@SanyaSho
Copy link
Contributor

@SanyaSho SanyaSho commented Jan 28, 2026

Description

When CProceduralTexturePanel calls it's CleanUp function it decrements the current texture handle ref index value and since the texture name never[1][2] gets changed you're left with a invalid texture until you restart the game

This fix will make each texture created by CProceduralTexturePanel have it's own unique ID, it will also make sure that allocated TextureID is cleared and simplify the texture creation code.

Video demonstration of a bug:

colorpicker_bug.mp4

Fixed version:

colorpicker_nobug.mp4

… created texture handle

CColorXYPreview panel is no longer trying to use decremented (invalid) texture handle from MaterialSystem
@robotboy655
Copy link

So, what I am seeing here are material and texture leaks. The panel creates a new texture and material with the exact same name, even if one already exists and never destroys them. (At least in my tests with GMod)
The PR would (kind of) fix the texture leak, but not the material leak.

Since they are procedural textures and materials, they will always have a refcount of at least 1 (ITextureInternal::CreateProceduralTexture and CMaterialSystem::CreateMaterial add one) and therefore never be freed.

This panel also creates a new TextureID every time the panel is created, but never destroys it. (CreateNewTextureID)

@SanyaSho
Copy link
Contributor Author

So, what I am seeing here are material and texture leaks. The panel creates a new texture and material with the exact same name, even if one already exists and never destroys them. (At least in my tests with GMod) The PR would (kind of) fix the texture leak, but not the material leak.

Since they are procedural textures and materials, they will always have a refcount of at least 1 (ITextureInternal::CreateProceduralTexture and CMaterialSystem::CreateMaterial add one) and therefore never be freed.

This panel also creates a new TextureID every time the panel is created, but never destroys it. (CreateNewTextureID)

Thank you for the review! I'll fix the TextureID leak soon.

I don't actually see how I can fix the material leak without replacing the CMaterialReference with a raw pointer or adding a new function that will not increment the refcount like CTextureReference::InitProceduralTexture.

@SanyaSho SanyaSho force-pushed the fix/decremented-texture-handle-fix branch from 5553618 to 624850f Compare February 11, 2026 20:08
CMaterialReference has a special Init function that creates the material using the same arguments and doesn't increment the refcount twice.
The material is now properly cleared on exit.
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.

2 participants