possible memory leak?

[polymorphicengine]

Hi, I'm encountering what seems to be a slight memory leak (?) with flo_draw = "0.3.1" and flo_canvas = "0.3.1"). I'm trying to do a simple animation by looping the canvas.draw function. This will steadily consume memory (not a lot, only about 0.2 mega byte per second), but i want my application to be able to run for very long periods (days) and i'm worried it will run out of memory eventually. Here is a very simple piece of code that also produces the issue, am I doing something wrong?

use flo_canvas::*;
use flo_draw::*;

use std::thread;
use std::time::Duration;

pub fn main() {
    with_2d_graphics(|| {
        let canvas = create_drawing_window("Window");
        canvas.draw(|gc| {
            gc.clear_canvas(Color::Rgba(0.6, 0.7, 0.8, 1.0));
            gc.canvas_height(1000.0);
            gc.center_region(0.0, 0.0, 1000.0, 1000.0);
        });
        loop {
            canvas.draw(|gc| {
                gc.layer(LayerId(1));
                gc.clear_layer();
                gc.rect(0.0, 0.0, 100.0, 100.0);
                gc.fill_color(Color::Rgba(0.0, 0.0, 0.0, 1.0));
                gc.fill();
            });
            thread::sleep(Duration::from_nanos(1_000_000_000 / 60));
        }
    });
}

[Logicalshift]

I've done some memory profiling and I think nothing's leaking in v0.3, but there might be a design issue here.

I think what you're seeing, at least with this program is that gc.rect() appends to the current path, so every frame here is appending to an increasingly large path, which is just the same rectangle drawn on top of itself over and over: it's this that's gradually increasing the memory usage. This can be fixed by calling gc.new_path() immediately before the rect() call. For me at least, memory usage seems to level out with that addition.

I think it's a design issue in that this isn't immediately obvious, so I'm going to think about ways this can be improved, probably for v0.4. My current idea is to make canvas.draw() reset the state of the drawing so that state from previous drawing calls can't cause odd effects, and maybe think a bit about the API for building up paths (which will probably be more of a breaking change)

[polymorphicengine]

thanks for looking into it, and yes in this example, adding gc.new_path() indeed fixes it, i thought that gc.rect() would automatically be a single path. But unfortunately, in my actual code, even adding that doesn't fix the issue and i can't really figure out why..

[Logicalshift]

I've managed to look into this some more. I think some of the examples like bounce might exhibit a leak too.

I've found a slow leak in the flo_stream library that might explain what you're seeing (but might also not account for the whole thing): we're usually retaining a 64 byte waker once per poll of the input stream - which should be once per frame, so maybe a bit too slow (although it's definitely possible to cause this more than once a frame). This is also cleared by certain events: it's a stream that's collecting wakers until it returns data.

I've spotted that 0.3 is generating a lot of CATransactions that don't seem to be being released (which is to do with the version of glutin that's being used): 0.4 changes to using wgpu as the renderer and doesn't seem to have that issue. I'm not sure if this is an actual leak or not (these could be in the autorelease pool and get tidied up eventually). v0.4 certainly doesn't seem to leak very much memory.

I'm going to fix the issue in flo_stream and see if I can spot anything else.

There's a chance that there's still some state accumulating somewhere too: this can be an issue like the path problem, but might be specific to the program you're running (some combination of changing layers and things like fill colours or textures, an error in managing GPU resources, or something. An unmatched push_state() call might grow memory at this rate too). I'm going to keep looking after I've fixed flo_stream to see if I can spot anything but I might need an example that exhibits the issue to figure out where it is.