Hey, well due to some circumstances ((namely compositor for via texture renders) I need to recreate Viewports on resize events. That part works fine. However if those viewports recreated hat processors I also need to recreate them. This also works. But each filter has a Framebuffer internally and I seem to be unable to delete them manually, as there is neither acces to them nor any other way of reaching the actual framebuffer without reflection.
In the statistics the memoryFramebuffer count increases to around 600 where the graficcard terminates with an out of memory opengl error.
SO basically the question is, is there any way to recreate Filters without causing massive leaks?
Your reported problem should probably be addressed as that seems like a real issue to me but I’ll let @nehon chime in on that one.
What I’m curious about is why the viewports need to be recreated. And even if they do need to be recreated then why can’t the fpp just be moved over? Partially I’m wondering if there is another issue with these and partially I’m wondering if there is a problem I will hit down the line that I haven’t hit yet now that I’m doing more with viewports.
The fpp has a resize method that is called upon viewport resize. I have the same question as Paul, why do you recreate the viewport?
About the framebuffer cleaning, I’ll look into it. Filter has a cleanup method that is called when the processor is removed (if I recall correctly).
Could you wrap up a small test case?
The framebuffers are only cleard on a full collection, even tho we could simple dispose of them directly via rendermanager and a check to ensure no double delete happens.
Due to dragging one window corner there happen up to 60 resizs per second massivly creating trash on the antive side. Normally this is no issue, as the Direct memory is large enough, but apparently the limits of cocurrently eisting framebuffers is far lower than this, as they cannot be swapped by opengl to main memory due to their nature.
public class Trasher extends SimpleApplication {
boolean tick = false;
private FilterPostProcessor fpp;
public static void main(final String[] args) {
BufferUtils.setTrackDirectMemoryEnabled(true);
new Trasher().start();
}
@Override
public void simpleInitApp() {
}
@Override
public void simpleUpdate(final float tpf) {
this.tick = !this.tick;
if (this.tick) {
this.fpp = new FilterPostProcessor(this.assetManager);
final BloomFilter trashproducer = new BloomFilter();
this.fpp.addFilter(trashproducer);
this.viewPort.addProcessor(this.fpp);
} else {
this.viewPort.removeProcessor(this.fpp);
// fpp.cleanup is indeed called by the rendermanager, but fails
// to properly clean up the buffers, even though a call to
// RenderManager.deleteFrameBuffer would solve this, but there is no
// way to access the used framebuffers from the outside.
}
}
So I’m now calling renderer.deleteFrameBuffer() in the FilterPostProcessor and in the Filter.Pass, and I also delete the textures (renderer.deleteImage) else, the texture number was stacking up a lot until they were reclaimed by the NativeObjectManager. That was draining quite a lot of fps.
Now i keep a stable number of frame buffer and texture…and fps is stable, but eventually at some point, the number of framebuffers in the stat view falls below 0… like -4 framebuffers. I guess that’s a stat view issue, or maybe some are deleted twice (no error though) and the statview doesn’t account for it.
I’m gonna check all filters for possible leak like this and commit. Still…this negative number of framebuffer bothers me.
The natieobject manager cleans them up on a full gc (double as well, so this is probably handled wrong if they are already deleted) In my version it then crashes as well with a not managed by nativeobjectmanager exception.
@nehon@EmpirePhoenix
There has been a “dispose” method on all native objects for quite some time. It is preferable to use it instead of the Renderer.delete*** methods.
There is/was the problem, the filterpostprocessor is not the native object, the contained pass is. but it’s impossible to get access to it. (Dosn’t matter wich way to get rid of it you use).
