Memory Leak

[matt-erhart]

 attributes: {
    someAttr: () => regl.buffer( array... ),
}

I just learned that this results in a context loss from a memory leak. I wanted to leave this here for future searchers, and understand what's happening. Why does creating the regl.buffer like the above cause a memory leak? Putting it outside the draw command works as expected.

[yoshuawuyts]

I'm not too familiar with the regl API, but from the looks of it my guess is that the function gets called on each draw, which copies the array and then allocates a new buffer. Does this eventually crash tho, or does it just allocate lots of memory and cause GC pauses?

…

On Sun, Sep 10, 2017, 21:49 Matt Erhart ***@***.***> wrote: attributes: { someAttr: () => regl.buffer( array... ), } I just learned that this results in a context loss from a memory leak. I wanted to leave this here for future searchers, and understand what's happening. Why does creating the regl.buffer like the above cause a memory leak? Putting it outside the draw command works as expected. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#430>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACWleuNd8ziK0OHDLdR7LgSCSQebVuDRks5shD0ygaJpZM4PSbkX> .

[matt-erhart]

Creating a new regl.buffer each frame sounds right.

Yea, it adds mbs to the ram per second crashes after 55-60 seconds and says the (regl) context was lost. Probably reaches some time/gb limit, and stops.

[jwerle]

@matt-erhart yeah returning an already created instance or just assigning the value of that attribute to be the buffer should suffice. you can update or reinitialize the buffer later . I've noticed a lot of overhead when using dynamic attributes (functions) over dynamic buffers

[gregtatum]

It appears to me you are creating WebGL buffers in a tight loop and they are not being de-allocated. There is nothing to garbage collect, as they are being added through the WebGL API, and not part of the garbage collector. This appears to be more of a user error, and nothing appears to be actionable from the side of the library, so i'm going to go ahead and close this.