Home » Android » Android Matrix multiplyMM in detail

Android Matrix multiplyMM in detail

Posted by: admin June 15, 2020 Leave a comment

Questions:

I’ve been wondering if anyone has some knowledge about

android.opengl.Matrix.multiplyMM

that they could share.

.

Reason for asking is, when learning through OpenGL ES, the method is widely used for all sorts of calculations. However, there is the android.renderscript.Matrix4f which I find working with more natural than with primitive float[] arrays. Problem is, the Matrix4f’s multiply function is using a temporary matrix to perform the operation, which results in being memory-inefficient.

One way to solve this is to create my own Matrix4f and write the multiply() myself. I was basing it around the following example. It may look horrible but saves me all the set()’s, get()’s and looping, which gives a performance increase.

But then, I still didn’t feel like letting the multiplyMM go. In the source you can read that the method is native, therefore should evaluate faster (yes?). And that made me wonder once again.

.

Therefore, does anyone know:

  1. What is the underlying algorithm in multiplyMM ? Does it use temporaries?
  2. Would it be quicker to use than self-written multiply?
How to&Answers:

1) The algorithm is matrix multiplication. This is the same stuff you learned about in your linear algebra class. (Source: http://androidxref.com/source/xref/frameworks/base/core/jni/android/opengl/util.cpp)

Does multiplyMM use temporaries? It’s native, so it doesn’t matter. If there is a temp variable, it’s allocated on the stack. No GC is involved because it is native.

2) Maybe. Just because it is written in C++, that doesn’t make executing the code faster. Why? There is overhead for switching from Java land into native code, and maybe that overhead outweighs the perf benefit from executing in native code.

Despite all of this, there are two more things to keep in mind: 1) Don’t prematurely optimize your code unless your sure this is a perf bottleneck, and 2) if you’re not sure, take some measurements. Do some profiling of your code to draw the right conclusions.