What happens, i have a text displaying the current fps, (always 2-3 digits), however I see a large amount of buffers being generated and trashed after a few seconds (up to 4 per frame wich quickly raise to a few thousand per second). (good that the fix for the tracking is in)
I investigated:
The assemble method generates a mesh with all letters in it.
When the buffer is not large enough a larger fitting one is created (like if the text gets more letters)
The problem here lies in the way the buffer.remaining() works.
Example Output from modificated ensureLargeEnough at bottom of post
Code:
136 but only 128 java.nio.DirectFloatBufferU[pos=0 lim=128 cap=136]
Enlarging to 136
solution:
Sequence of problem:
2 letter text, allocated first time buffer for two letters, everything fine limit set for two letters
text increases to three letters, larger buffer is allocated, limit set for three letters, still fine
text is 2 letters again, old buffer large enough, limit set for two letters
----
text increases again, three letters, however limit was set to two letters, so remaining returns not enough space, a new buffer the same size as the current is created!
This leads to a overloaded gc, wich creates unneccessary out of direct memory crashes, since it is occupied with collection the leaking buffers.
Code:
// increase capacity of buffers as needed
fpb.rewind();
fpb = BufferUtils.ensureLargeEnough(fpb, vertCount * 3);
fpb.limit(vertCount * 3);
pb.updateData(fpb);
Code:
public static FloatBuffer ensureLargeEnough(FloatBuffer buffer, final int required) {
if (buffer == null || buffer.remaining() < required) {
System.out.println(required + " but only " + buffer.remaining() + " " + buffer);
final int position = buffer != null ? buffer.position() : 0;
final FloatBuffer newVerts = BufferUtils.createFloatBuffer(position + required);
System.out.println("Enlarging to " + buffer.capacity() + " ");
if (buffer != null) {
buffer.flip();
newVerts.put(buffer);
newVerts.position(position);
}
buffer = newVerts;
}
return buffer;
}