FloatBuffer.put() bug...

by Patrick » Fri, 23 Jan 2009 04:51:24 GMT

Sponsored Links
 There seems to be a bug where calling FloatBuffer.put() on a buffer
create as such :

ByteBuffer bufferVerts = ByteBuffer.allocateDirect(numVerts * 3 * 4);
m_bufferVerts = bufferVerts.asFloatBuffer();

does not properly write. Basically, calling :


does not give a vert at that location. The vert location is random
(Changes each time I run the app), indicating that put did not write
anything, leaving memory to whatever garbage it initially had.

However, calling

m_bufferVerts.put(0, -0.5f);
m_bufferVerts.put(1, 0.5f);
m_bufferVerts.put(2, 0.0f);


I can keep my own position counter, but since FloatBuffer claims to
have one internally, shouldn't those two pieces of code have the same


FloatBuffer.put() bug...

by fadden » Fri, 23 Jan 2009 06:53:52 GMT


There are some known problems with the 1.0 implementation, e.g.:


Can you provide a stand-alone class that exercises the problem, with
expected vs. actual output?  (If it's a stand-alone main() we can run
it under a desktop VM and under Dalvik and compare the results.)


Sponsored Links

FloatBuffer.put() bug...

by Patrick » Fri, 23 Jan 2009 10:06:38 GMT

 As a standalone app, it might be difficult, since the problem does not
seem to occur if we look at content of the buffer through java code.
But it does have a problem if openGL tries to access it to render, so
to get the bug requires a lot of code around it.

To get the bug to repro, in the API demos, in Cube.java :

- Remove line 75.

- After the call to mVertexBuffer.position(0), add the following
code :

        for (int i = 0; i < vertices.length; i ++)

Essentially adding vert data one entry at a time, instead of in one

You'll see the "cube" displayed is not a cube at all. The verts are
messed up. But how it's messed up is different each time you run it.


FloatBuffer.put() bug...

by Woerf » Mon, 26 Jan 2009 20:15:46 GMT

 When you move that loop behind mVertexBuffer.position(0) you'll pass
the buffer with position at the end in the draw method. You have to
reset the position after you put values into the buffer. If you do
that the demo doesn't show the errors anymore.

If this should actually even work the way you described it, then I
guess the methods that get called later should handle this. To me it
seems like openGL just reads outside the buffer that was passed. I'm
not sure if this should be tolerated.


Other Threads

1. Problem in sending sms


I am trying to send sms using SmsManager class.Here is my code:

PendingIntent pi = PendingIntent.getActivity(this, 0,
new Intent(this, SMSSender.class), 0);
SmsManager sms = SmsManager.getDefault();
sms.sendTextMessage("9001100444", null, "This is test message", pi,

SMS is sent successfully but it is sent two times on the same phone-
number and aving same content.

I dont get the problem.Can anyone describe me the reason of this

Thanks in Advance

2. first frame of a video file

Can anybody help me with getting the first frame of a video file taken
with the camera?

3. Issue with WindowManager showing UI

4. Module and App

5. Nexus one reporting 533 as Height!?!

6. Update SQLite Database from other app

7. Gallery view not working well