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. {WTA} Cara install aplikasi keMicroSD Card di 1.6 Donut

Androiderz..! ;-D Nubie mw nany,,klo mw install aplikasi ke MicroSD card
gmana yaaa..? Jd installan aplikasi ga' numpuk di Internal Memory..!
Pke aplikasi ap mngkin?

Ane pke HTC Dream (G1) 1.6 Donut! (Bkn 1.5 Cupcake)

Tengz elot..! ;-)

I'm nu Android fanz ;-)

"Indonesian Android Community [id-android]" 

2. Content provider implementation questions

Hi, All

I'm now trying to implement my own content provider. My original data was
stored on network or local/remote file systems, so I want to provide data
via input stream. I know that client may call ContentResolver.getnputStream
to retrieve the input stream to access data. But I don't know how to
implement content provider in this situation, I searched the Internet but
all the tutorials for content provider are talks about how to expose data
that stored on local database.

Could anyone please help me on this or give me some code snippets to show
how to expose data that stored on file systems using a content provider?

Also could anyone please tell me what happened when client
call ContentResolver.getnputStream? I want to know how to return an input
stream to my client.

Thank you



3. How to send mms from my code

4. Service Vs Thread

5. video resolution 3gp file

6. Replace dialer application by installing another dialer app

7. dalvik and defineClass