- My matrix operations in Java are slow

- Uploading 5 matrices regularly is using up my bandwidth?

Probably neither. Unless you've got a really really bad matrix library, or an absolutely huge amount of matrices to upload, both of which are extreme and unlikely scenarios, you'll need to look elsewhere.

That UBO update - that's what I'd point my finger at. There are threads about UBO performance and how slow they are to update, as well as the hoops you need to jump through in order to make them fast again.

Before we go any further this is worth testing and fortunately it's an extremely simple and minimally-intrustive test. Just convert to standalone uniforms from a UBO. See if things improve. If they do then we've established that yes, it's the UBO that's causing your performance problems.

Also, instead of working out the model view proj matrix on the CPU, do the multiplication in your shader. GPUs are far better at matrix multiplication in almost any situation.

...but the CPU typically only has to do this particular multiplication once, whereas the GPU will need to do it per vertex. Yes, the GPU is faster, but tens of thousands of times per frame versus once? It's not that much faster.

If you modify a model matrix, don't update your projection matrix just for shits and giggles, that's inefficient and a huge performance drop. Imagine how many times per second you are doing that!

You don't update the uniforms each time you modify a matrix.

First you do all your computations (rotations, translations, scaling, model view projection, whatever) for all your objects. Then, when you're about to draw the mesh, you update the uniforms for that object.

Upload them only once just before rendering - though the driver will probably already do this for you behind the scenes.

The more important point you might want to consider is how you measure your performance. If you get >1000fps with those various effects, your scene is probably too small to test on. If your rendering is not the bottleneck, then your memory lanes are. So you could probably throw a way more complex scene at the program and it'd run at the same speed. Another point is that measuring with fps can be deluding - a drop from 1200fps to 170fps is not that massive, the render times went from 1ms to 6ms - you should maybe measure which parts take how much time, opengl has time query objects for this.

I'd counter-argue that going from 1ms to 6ms is extremely significant, particularly if all other factors are equal between the two tests. You've just blown one-third of your frametime budget on ... nothing. Yes, that's significant.

Now, if it was going from - say - 8ms to 13 ms, you'd have a point, particularly if there was a nice new effect, higher LOD, or whatever to look at in return for it. Blowing one-third of your frametime budget just on account of using a different way of doing the same thing? Nope, you don't have a point, sorry.

whereas the GPU will need to do it per vertex.

If your graphics drivers are any good, it will only do the multiplication once. If your driver can't perform this optimization, switch gpu vendor.