Open sejori opened 1 month ago
Hi @sejori,
Thanks for reaching out and using this repo. I have taken a look at the above code and without some of the other portions I wont be able to help completely.
The bindFramebuffer
and framebufferTexture2D
are not need a lot of the time due to have a different fbo that is attached that angle itself calls to render most items. When you call them they are making new ones that will need to have a different source texture to get attached to then rendered after calling the activate texture then updateTexture.
This and this are other more complicated ways to render using this package.
If you give me more of the code I can see if I can help. I would need the updateTexture function and splatProgram.
Sorry I am unable to help, but please see if you can give me more info.
Thanks
Hey @Knightro63
Thanks for your response.
I uploaded our code here
It would be great if we could hear your thoughts and confirm that the usage of the library is correct.
Hi @sejori and @alexgrusu,
I submitted a pull request to the repo provided and I think I found your issue.
Let me know if you have any other questions.
Hey @Knightro63 ,
Thanks for your valuable feedback. This was helpful.
We are running into an app freeze after running the shaders animation for a while.
I see you are calling _rc.flush();
on every update, is there anything else we need to clear from time to time?
Also, we see that the animation is a bit blurry. Is this something we can fix in any way?
Screenshot for the blurry effect
Hi @alexgrusu,
I looked at you demo again and noticed that some of your buffers were called continuously and not deleted everytime which would cause a memory leak. This is probably why your app would freeze after some time. I was able to find some of them, but you would need to go in and find the rest.
As for the blurry animation, this can be fixed by binding your texture to a larger size than your width and height. Then rebinding it to the correct size, kind of a janky way to increase your resolution. Here is a form for which they answered this.
Hope this helps.
Hi @alexgrusu,
I looked at you demo again and noticed that some of your buffers were called continuously and not deleted everytime which would cause a memory leak. This is probably why your app would freeze after some time. I was able to find some of them, but you would need to go in and find the rest.
As for the blurry animation, this can be fixed by binding your texture to a larger size than your width and height. Then rebinding it to the correct size, kind of a janky way to increase your resolution. Here is a form for which they answered this.
Hope this helps.
Hey @Knightro63 ,
I'm extremely grateful for your help.
Just to confirm my understanding, maybe my question is dumb because I don't know what is happening behind the scenes.
Whenever we create
a buffer, bind
, and draw
the elements, at the end we need to call deleteBuffer
. Is my understanding correct?
Are there any other scenarios when we need to call deleteBuffer
? Or what's the sequence of calls we need to follow to ensure we don't lead to any memory leaks?
Hi @alexgrusu,
Yes this is true. In your bilt function you create 2 buffers each time but they are never deleted afterwards.
If you go to my fork I have updated it with the correct bilt function.
For anything that is created for the gles program you will need to delete them after they are done. This is true for framebuffers, textures, buffers, vertexarrays, ect. In most of your case it looks correct all of the items you create you use over and over, which will not need to be deleted for each update, but they will need to be deleted if you go to a different portion of you app.
There is still one in there that I was unable to find; this is causing a small memory leak.
Hope this helps.
Hey @Knightro63 ,
How do you investigate the memory leaks? Do you use flutter dev tools or something else?
Is it possible to use something like Valgrind?
Also, do you have any thoughts about the following error?
E/emuglGLESv2_enc( 8847): device/generic/goldfish-opengl/system/GLESv2_enc/GL2Encoder.cpp:s_glDrawElements:1479 GL error 0x506 condition [ctx->m_state->checkFramebufferCompleteness(GL_FRAMEBUFFER) != GL_FRAMEBUFFER_COMPLETE]
Hi @alexgrusu,
For memory leaks I use XCode. I know you are using an Android device and the flutter dev tools should be able to show you the memory information as well.
For the error it might be due to checkFramebufferCompleteness not being implemented at this time.
Hey @Knightro63 ,
Considering we run through different contexts across the app, is the FlutterAngle.initOpenGL
call required every time before running the GL work, or do we have to call this only once during the lifetime of the app?
Also, I don't see any support to release/dispose resources to OpenGL. Is this required?
Hi @alexgrusu,
Yes you only need to call initOpenGL once. You can call it more but it will only use the initially created library.
If you want to remove the texture from FlutterAngle call FlutterAngle.deleteTexture
.
Hope this helps.
Hi there, great work on your library - thanks :)
We have an issue when creating new textures and Framebuffers to store off-canvas data. The issue is that we cannot get the render target to return to the default texture after calling
gl.bindFramebuffer
andgl.framebufferTexture2D
.Here is our FBO class:
And here is the
initPlatformState
from our test implementation, based on your example:With the
velocityFBO
instantiation the screen goes white but no errors show. When we remove the call to FBO we successfully render the "splat" fragment. We can also see that if we comment out the following two lines from theFBO
constructor we can continue to render as expected:Which leads me to believe the issue lies in binding new frame buffers and textures to the canvas.