sf::Text::setCharacterSize() memory leak, maybe (Solved)

[PupperGump]

I made a gui and I am using a slider to change the font size of a text. The memory remains stable when not changing the value, but every time it's changed it increases memory use. So if I swing the slider back and forth a bit, it eats up my 32GB memory very quickly.

Is it supposed to do this and should I be scaling instead of changing the character size?


Edit: I fixed this issue by using this font function in sf::Text::setCharacterSize()

void Font::clearPages() const
{
    // Reset members
    m_pages.clear();
    std::vector<std::uint8_t>().swap(m_pixelBuffer);
}

[eXpl0it3r]

Whenever you change the character size and render text with it, the glyphs for these characters have to be re-rendered. If you do this change in real-time for every value selected, it will render out the glyphs for all the characters in all the different font sizes.

There's currently no way to explicitly clear the usage and in a lot of cases you don't want to do this whenever changing font sizes for performance reasons (e.g. rendering two sf::Text at different font sizes).
One way to reduce the memory pressure would be to add a small delay in selecting the font size, so you're not loading everything on the slider, but only load the value after say 500ms. It might not be as seamless, but it would reduce the memory load.

[Hapax]

Following on from eXpl0it3r said, you could use a text's scale to show the different sizes while actually moving the slider (to show a preview of the future size) and then change the actual character size when the slider is released.

[PupperGump]

Those would be good optimizations, but I see no real performance decrease (on release, /02) unless changing fonts about 100 times per second. Even with multiple fonts, the memory only rises depending on the amount of text and whether it's changing, but does not exceed 2 GB in the most extreme cases with multiple fonts. I still get a steady 500fps when changing font size every frame.

Overall I think there's not much need for optimization other than maybe increasing the max cache size a bit. The way I see it, if there's a fix in place and there's performance issues, it's a user flaw. But if there's no fix at all and memory leaks persist, it's an SFML flaw.