Q: Android OpenGL dynamically size FloatBuffer? I'm trying to build an OpenGL ES 2.0 rendering system on Android.
I have one FloatBuffer, in which I put all vertex data. Currently, I just allocate it with a huge number of bytes and ignore draw calls if they would overfill the buffer at that size.
Is there a way to dynamically resize the buffer? If i just freed the buffer and reallocated it after every render, I imagine that would be very slow.

A: I am actually still in the process of learning high performance OpenGL rendering, but switching over to Vertex Buffer Objects usually allows the highest possible execution times. In the end you have to try it out and test.
Here some sources for further reading:


*

*Android Lesson Seven: An Introduction to Vertex Buffer Objects (VBOs) 

This is fine when there is not a lot of data to transfer, but as our
  scenes get more complex with more objects and triangles, this can
  impose an extra cost on the CPU and memory usage. What can we do about
  this? We can use vertex buffer objects. Instead of transferring vertex
  information from client memory every frame, the information will be
  transferred once and rendering will then be done from this graphics
  memory cache.


*OpenGL Vertex Buffer Object (VBO) -> Updating VBO

*Vertex Specification Best Practices -> Dynamic VBO

A: 
Is there a way to dynamically resize the buffer?

No. Your current approach looks fine. You may want to extend it, that if the data doesn't fit in the current buffer, that you create a new, bigger one and fill it with the new data. 
Unfortunately OpenGL-ES doesn't have a function as OpenGL-3 does which allows you to copy data between buffer objects. Using that you could to a copy between BOs that stay entirely in GPU memory, so that you'd have to update only the missing parts.

If i just freed the buffer and reallocated it after every render, I imagine that would be very slow.

It will not increase performance for sure, that's right. Depending on your actual implementation it may have a huge impact on performance, that's right. So I advise against doing this.
