You might want to try to apply the controller just once, remove it and call build afterwards. Just to see if that changes something. It shouldn't, but just to rule that out...

That the amount of work done in fillAttributes increases when you are using vertex attributes is to be expected. I'm more confused about the fact that there seems to be significant work done in the other case as well. Are you, even in case of using the vertex attributes, still assigning the vertex controller? Or do you have some explicit calls to compile(...) or maybe build(false)?

The actual rendering will take the same amount of time, no matter now much of the object has been modified. If you are using a vertex controller, it requires a transfer of data from main to GPU memory that takes additional time. Your shader based solution should avoid that. Have you profiled your code to see exactly where the time is being spent? Also, you large is the object in question?

I see. There's no functionality that does this automatically. You have to model it that or come up with some algorithm to do it (which won't be trivial...).

You mean the matrix that transforms from world into camera space? No, that's not present by default but you can add a uniform to your shader and inject it yourself. Something like this should work:

SimpleVector pos = camera.getPosition();
pos.scalarMul(-1f);
Matrix mat = new Matrix();
mat.translate(pos);
mat.matMul(camera.getBack());
...
shader.getUniform("viewMatrix", mat);


The "old" purpose of multiple threads is indeed to do slow IO operations in the background. But nowadays, given that all processors have multiple cores/threads (the machine I'm writing this on can handle 24 threads in parallel, for example), it also very common to use multiple threads for calculations.
That said, it's not easy to use multiple threads for physics, because the result of one thread's calculation can have an impact on the other. Imagine 8 boxes colliding with each other. If you calculate each box in it's own thread, the outcome of one would depend on the collisions of all the others, which is almost impossible to synchronize properly.
jPCT(-AE) itself isn't thread safe (but you could do calculations on independant objects or tasks in multiple threads) and neither is OpenGL(ES). If you want to use multi-threading in one way or the other, you have to make sure that the tasks that are processed by the different threads are independant (for example: One thread for physics, one for sound, one for path finding...).

This should be the code Thomas. released back then: https://jpct.de/download/example/PhysicsTest.zip

Please note: I've just zipped my project directory. It might contain a lot of unneeded stuff and was created for an Android-SDK from ages ago. That said, it still compiled, uploaded and worked fine for me.

I'm not sure what you mean, because there is ARBMultitexture-stuff in your code anyway. However, it might be worth a try and see if your constants are the same as they are in normal OpenGL. These should just be integers and if your toolkit isn't doing something really strange with them, something like PrimitiveType.Triangles should have the same value as OpenGL's GL_TRIANGLES.