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. remote views

hi all,
i am trying to change the text of layout throug a backround activity
(not sure what it is going to be activity or....)
say i have a an activity a with a screen layout a_l. i want o chane
the text of a text view in this layout. from another class...
is it possible..
how can i do it..


2. Android Emulator Frozen On Splash Screen

Hi Everyone,

I thought I would share this problem and it's solution so others may
benefit. I was having a problem where the emulator would freeze
indefinitely on the Android splash screen.

I left it for hours with no success.

The problem appeared to be a corrupted avd. I deleted the .android
folder. Recreated the avd and the problem went away.

I think i caused the problem by killing the emulator while it was
generating the images on the first boot. I grew impatient after a few
minutes and ended the process. From then on the emulator wouldn't

Kind Regards
Jared Kells


3. Oops, sorry everyone!

4. MOHIT -The Evil Hackerz

5. latest software downloads

6. Buy stunning collection of diamond jewelry

7. Problems with Cupcake OTA update for ADP1