-
Notifications
You must be signed in to change notification settings - Fork 322
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Memory Leak #430
Comments
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>
.
|
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. |
@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 |
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. |
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.
The text was updated successfully, but these errors were encountered: