darthdeus / comfy

Comfy is a fun 2D game engine built in Rust. It's designed to be opinionated, productive, and easy to use.

Home Page:https://comfyengine.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

External issue: Memory leak when drawing 100 sprites (maybe dependency bug?)

nokola opened this issue · comments

I have small .png as sprite for stars and this drawing code:

fn draw_stars(world: &WorldBounds, stars: &Vec<Star>, bg_stars: &Vec<Star>) {
    for star in stars {
        draw_sprite(
            texture_id(TEX_STAR),
            star.pos,
            BLUE * 5.0, // TODO: other color?
            0,
            Vec2::splat(star.size),
        );
    }
}

Expected:
no mem leaks when running above in update()

Actual:
When I run it, memory increases about 50MB/second - waited until 10GB were used.

Note: If I comment it out, the memory growth stops.

Update: could be a dependency (Accrete) bug, looks like some sort of memory corruption possibly.

Updating with example from comfy/examples/sprite.rs:

  1. Add accrete to comfy/Cargo.toml:
accrete = "0.2.0" # for planet system generation https://crates.io/crates/accrete

image

  1. Update examples/sprite.rs like so:
use accrete::Accrete;
use comfy::*;

simple_game!("Sprite Example", setup, update);

fn setup(c: &mut EngineContext) {
    c.load_texture_from_bytes(
        // Every texture gets a string name later used to reference it.
        "comfy",
        include_bytes!(concat!(
            env!("CARGO_MANIFEST_DIR"),
            "/../assets/comfy.png"
        )),
    );
}

fn update(_c: &mut EngineContext) {
    for _ in 1..10000 {
        draw_sprite(
            // Drawing sprites/textures requires a TextureHandle which can be calculated from its
            // string name. This incurs a non-measurable overhead in hashing the string, but saves
            // a lot of boilerplate in user code that would have to store asset handles.
            texture_id("comfy"),
            Vec2::ZERO,
            WHITE,
            0,
            splat(5.0),
        );
    }
}

image

  1. Run cargo run --example sprite

Expected: no memory leak
Actual: memory leak depending on how many sprites we draw.

Looks like accrete depends on wee_alloc which may be causing this problem rather than the default allocator.