BufferUtils tracking reimplementation/fix

Development
21

@Momoko_Fan

@nehon

@pspeed

@norman

(Forgot anyone? if so sorry)



Well since its been a while and the old not working code is still in the svn and after seeing all the fuss with imageraster lets try to boost communication a bit. What I hope to archieve here is getting opinions and hopefully find a solution that will be fine for everybody.



Will this be integrated as a fix for the current implementation?

Will the whole tracking stuff be removed?



I guess both would be solutions, I would prefer the one with the tracking implementation.



My reason why I think one makes sense:

The jvm does a somewhat poor job on managing the direct memory, having a tracking implementation helps to see potential flaws like leaking procedualy textures,meshes, ect.

Also it helps to adjust the scenes in a way to make them better performing on the target hardware.

(If the direct memory used is more than the vram, the opengl driver must swap stuff out and in again, this usually results in microlags on fast turning on the player and/or bad framerates)

22

I still have it on my to-do list to look at integrating this when I have more JME time… and if someone else doesn’t get to it first.



I agree that we should either integrate the changes or take out the tracking.



I generally point to this thread as an example of where communication worked well… I just haven’t had the cycles to follow up with the actual work myself.

23

I can take care of it, but some things bother me :



@EmpirePhoenix

This thing is only for debugging purpose right? so the cons you mention “slightly slower” does not really apply to a packaged game?



Then :

@pspeed said:
As long as this defaults to "off" then I don't have a real problem with it.


[java]
private static final boolean trackDirectMemory = true;
[/java]

We need an API to set it on or off, we don't want users to have to pull the full svn and compile their own JME to monitor direct memory.
24

Hm yes adding a static setTracking(boolean value) might be a good idea here. I agree.

Actually it might be a good idea t introduce a Facade somewhere in JME3 for all debugging systems so you can configure those in a central location. (Logger, physicdebugdrawing, memory, ect)



And maybe a check that ensures the application is not running already.

Performance wise it wont matter, the jit compiler is good enough to realize that the boolean is not changing and compiling all the branches out.

25

@EmpirePhoenix

mhh why did you remove the createFloatBuffer(Vector4f… data)



Just a mistake or is there any reason?



EDIT : forget it it’s been added since your patch

26

Yes, this i why I don’t like this being stale for so long, the longer we wait for a decision the more outdated it will become.

27

Ok it’s in.



I tested it and it works fine.



Default is disabled, you can enable memory tracking using BufferUtils.setTrackDirectMemoryEnabled(true);



I added a hint in the output when you print the memory usage if it’s not enabled.



Also i removed all unnecessary final and BufferUtils. prefix from your code because as it’s slightly a big change and I wanted the diff in the commit log to reflect what actually changed and not formatting/good practice changes.



please update and test and tell me if i did something wrong :wink:

Thanks for the patch

2 Likes