On the problem of slint memory leak

[pcevent]

Hello!
I made a small demo (using a timer to continuously increment a value on the interface). During operation, the memory is constantly increasing. Is it a bug or a cache caused? If it is caused by caching, how should it be turned off?

appwindow.slint

export component AppWindow inherits Window {
    property<int> counter: 42;
    callback inc();
    inc() => {
        counter += 1;
    }
    Text {
        text: "Counter: \{root.counter}";
    }
    width: 200px;
    height: 100px;
}

main.rust

slint::include_modules!();

use slint::Timer;

fn main() -> Result<(), slint::PlatformError> {
    let ui = AppWindow::new()?;

    let timer = Timer::default();
    let uh = ui.as_weak();
    timer.start(slint::TimerMode::Repeated, std::time::Duration::from_millis(20), move || {
        let ui = uh.unwrap();
        ui.invoke_inc();
    });

    ui.run()
}

[tronical]

Hi! Thanks for the report. What platform are you running this on? Do you know what backend you're using? (winit or Qt)

[pcevent]

I am running on MacOS and using winit.

[ogoffart]

What's your platform (opereting system) and do you know what graphical backend you are using? (Qt, Femtovg or skia?)

The memory should increase too much.

Maybe vallgrind's massif or heaptrack tools can help to find out where the memory is spent.

We do have some cache. For example the image cache

slint/internal/core/graphics/image/cache.rs

Line 46 in 757a744

clru::CLruCacheConfig::new(core::num::NonZeroUsize::new(5 * 1024 * 1024).unwrap())

which van be 5M big.
But that example shouldn't be using the image cache.
There is another cache in femtovg for fonts. but it shouldn't increase since that's always the same font.
there might be some other caches.

[pcevent]

Above is the complete code。

[ogoffart]

I could reproduce the problem.
And I measured with heap track, looks like the curflpit is the femtovg text:

[ogoffart]

As @tronical pointed out to me, this is caused by 8b7a744 which increase the cache size to be a bit too large.
We probably should decrease these number to some more reasonable values
But the cache is still bounded so it won't grow forever.

[pcevent]

May I ask how to solve this problem?

[pcevent]

Okay, thank you for your reply.

[tronical]

Another workaround would be to use the Skia renderer. But we do need to fix this in either FemtoVG or our use of it. I'll create an issue in any case.