One of the things I was looking at was trying to create "moving" graphics with OpenGL. All the examples that show you how to create OpenGL told me that I need to use a java.nio.Buffer (IntBuffer or FloatBuffer for example), because these buffers are allocated in native memory.

One of the problems I have is that this makes using variable arrays rather difficult. This would be needed for example to bring a ripple in water or create a "sinusoid" line. I used the FloatBuffer.wrap() call to work around this, but I wonder if there are any side-effects that might prohibit me to work this way ? On my HTC Magic it works fine, and I have attached a project which shows how to do it here.

Any comments from the graphics Gurus ?



The actual code which changes the values in the arrays:



I know that this code uses an indirect NIO buffer, but would it hurt ?

Create the buffer once with the following code snippet.

All you have to do is do a put on the buffer that you save between frames with the local float[]. Also if you do any single value puts always do absolute puts instead of relative for speed. If memory is not a problem then keep a local float[] and do just one put per frame.

The following are a few methods in my BufferUtils class that creates a direct FloatBuffer.



While you are using indirect buffers with wrap and it seemingly works there quite likely is some sort of conversion happening at a lower level in the Android GL implementation quite possibly creating a direct buffer each frame (one must verify this; just an educated guess!). Use the debugger (ddms / command line tool) and check it out. I didn't run your example, etc. Various GL bindings will do different things. If I recall correctly for instance LWJGL will throw an exception when the buffer is not direct.

You can improve this loop. You are already counting backwards with a >= 0 check which is the fastest, so that is good.



You can do a few more things to speed up this loop. First perhaps look into "inflating" the counter. If the FLAG_LEN is 10 then make counter 30 and decrement by 3. This will remove the counter*3 multiplies (also if you ever have to do the same operation twice or more store it in a temporary variable). The next thing you can do is unroll the loop. Do 10 iterations in one loop cycle. If you don't know the length of the flagCoords before running the code look into something called Duff's device. If you are working with the same length object each time you can calculate any variables for Duff's device once or simply have a tailor made unrolled loop.

As it is I'm sure for one waving flag you get a nice frame rate, but with more dynamic objects per frame things can slow down fairly quickly. You can also test and see how adding more flag coordinates scales and simply place your camera / view further away.

Thanks for your reply, a real good explanation! I have used the direct buffers before, just like you suggest, but I had trouble in putting the updates back into the buffer. I know I can do a put(index, float) and will most likely adapt my program in using it.

The example code is far from optimized, I know, the main goal was to get something working in a "quick" and dirty way.

The sample program did not create any new objects, nor did it cause any GC happening. But ... the main reason for getting away from the indirect buffers, created by wrap is that indirect buffers can no longer be used. I read somewhere that Android will do checks in the future to avoid using them. Another reason is that although it seems like the indirect buffer is "fixed" in memory, there is no guarantee that the JVM will not reallocate it sooner or later. If this happens between the glVertexPointer call and the actual draw, you would be in trouble.

Coming back to the use of direct buffers and using "put" to change the values:

When I tried it first, I saw all kind of lines being drawn, which made no sense to me. Using "wrap" fixed this, but wrap is no option. I tried putting "synchronized" around the code, but it did not fix it either.

I realize now, that if to avoid these spikes, I need to do the copy from the float[] array into the buffer during the call to my "onDraw(gl)" call.

If I want to have a waving flag, I will need to update all vertices in most cases, so I wonder it it might be faster, if I do something like this:



Or should I do individual "puts" for all float values in the array?

cg0601 wrote:I have used the direct buffers before, just like you suggest, but I had trouble in putting the updates back into the buffer. I know I can do a put(index, float) and will most likely adapt my program in using it.

Doing put(float[]) will be fastest quite likely, but don't forget to call "rewind" after the put. I can't recall off the top of my head if you have to have the direct buffer in the rewind state before sending it to the Android GL implementation, but that is what I do and I do recall LWJGL and/or JOGL complaining / not working if the buffer is not rewound. "position(0)" should effectively be the same thing, but I always have used "rewind".

Try both the absolute single puts and filling a float[] and a single put. If you can spare the memory overhead of having a local float[] for your app quite likely that will be the fastest over absolute single puts.

cg0601 wrote:The sample program did not create any new objects, nor did it cause any GC happening.

Your program may not be creating new objects, but the underlying Android GL implementation might be doing that. There is a nasty FloatBuffer to ByteBuffer conversion or something screwy under the hood as far as object / memory creation with glDrawElements and other methods. Something similar could be happening when you are using indirect buffers. You'd see it when profiling with the debugger / ddms.

cg0601 wrote:Coming back to the use of direct buffers and using "put" to change the values:
When I tried it first, I saw all kind of lines being drawn, which made no sense to me. Using "wrap" fixed this, but wrap is no option. I tried putting "synchronized" around the code, but it did not fix it either.

I realize now, that if to avoid these spikes, I need to do the copy from the float[] array into the buffer during the call to my "onDraw(gl)" call.

If I want to have a waving flag, I will need to update all vertices in most cases, so I wonder it it might be faster, if I do something like this:

Syntax: [ Download ] [ Hide ]

Syntax: [ Download ] [ Show ]

Using java Syntax Highlighting

1. floatBuffer.position(0);
2. floatBuffer.put(flagCoords);
3. floatBuffer.position(0);
4.  

Parsed in 0.035 seconds, using GeSHi 1.0.8.4

Or should I do individual "puts" for all float values in the array?

Yep.. I do something like this:



You don't need the "rewind" in front or "position(0)" if the buffer is already rewound. The individual absolute puts shouldn't be faster than filling a local array and one put, but it might not be too bad; relative puts is where performance can degrade with dynamic buffer filling.

Quite possibly the errors / lines and other artifacts you had previously is due to improper rewind state / buffer filling.

Best of luck!

Thanks for your tips, I managed to get the waving flag working and can easily obtain 20 fps, even with 2 flags waving.
The main reason why I saw the lines, etc was due to the fact that I let my GLSurfaceView do a continuous rendering, which is the default. Somehow it seemed to decide to do them in the middle of my updates.

Setting the mode to RENDERMODE_WHEN_DIRTY and call "requestRender()" from a timer got rid of these problems.

Next project is rain drops in water, but here the CPU speed is the main problem. I got something working alright, but the calculations to do the graphics need > 1.5 second, so I can do only 0.5 FPS, which is no fun at all.
Doing the Graphics, even using Canvas takes like 8-10 ms, so I did not bother using OpenGL yet.
Guess, I'll have to wait till I upgrade my Magic to something faster.
BTW, the calculations is all int- based, so not even need for doing float calculations.

(Side-note 1: I wonder how they do it on the iPhone, I don't think their CPU is so much faster ? Unless they have a math co-processor)
(Side-note 2: Maybe I need to go to JNI code to do the arithmetic ?)

iPhone does have a co-processor, floating point calculations are more friendly there.
On Android, for such heavy calculations as yours, JNI will increase performance for sure. I heard that in the next Android release (2.2) there will be a JIT compiler, so all applications will run much faster in heavy-math scenarios.