I also ran into this problem. After looking through the source to
the NIO buffers I noticed that when you use a wrapped direct buffer
the wrapping code doesn't clear the underlying buffers position when
you call buffer.clear(). I found a way around this that doesn't
require the for loop. If you call buffer.compact() right after
calling buffer.clear() it will call the underlying direct buffers
compact and clear methods. And since you just called clear there
isn't anything for the compact to do so it's almost a NOP. The
resulting code to fill a buffer is:
buffer.clear();
buffer.compact(); //This forces the underlying direct buffer to be
cleared.
buffer.put(array);
buffer.position(0);
I didn't find that I needed this with the Float buffers. But I
did need it for Short or Integer buffers.
-Anton
On Mar 30, 1:31 pm, Streets Of Boston <[email protected]> wrote:
> Good to know. At least it's good to know that i was not going crazy :-
> D
> I used the for-loop solution to get around this issue.
>
> On Mar 30, 7:04 am, Daniel Johansson <[email protected]> wrote:
>
> > I'm experiencing the same behavior, and I'm pretty sure it's a bug.
>
> > I have been testing this thoroughly and it simply does not work to put
> > an array och another IntBuffer into a "direct" IntBuffer.
>
> > intBuffer.clear();
> > intBuffer.put(otherIntBuffer);
>
> > This does not work if "intBuffer" is a direct IntBuffer. It does work
> > for indirect IntBuffers and also for direct/indirect FloatBuffers.
> > The error shows itself through that the intBuffer.clear() operation
> > does not clear the buffer the second time i run this code. That means
> > the next put() will append the new information to the old and there is
> > a buffer overflow.
>
> > The workaround is to create a for-loop that puts one element at a time
> > from "otherIntBuffer" into "intBuffer". Or to use FloatBuffers.
>
> > On Feb 2, 4:24 pm, shaun <[email protected]> wrote:
>
> > > I am trying to optimize the OpenGL ES rendering pipeline, along with
> > > general optimizations for a proof of concept. One thing I did was to
> > > take vertex and texture coordinate float[] data and FloatBuffer that
> > > are passed to gl*Pointer methods and convert them into int[] data
> > > andIntBufferobjects, because I am using GL_FIXED and fixed point math.
>
> > > After initializing/allocateDirect()'ing the IntBuffers and put()'ing
> > > the int[] data in them for the first time, the render() method is
> > > called once per frame. After the rendering, the int[] data is updated
> > > for both vertex and texture data. Then, the following methods are
> > > called on theIntBufferobjects:
> > > -vertices_buffer.clear()
> > > -vertices_buffer.put(vertices) // vertices is a int []
> > > -vertices_buffer.position(0)
>
> > > This was not problem when using float[] and FloatBuffer, but a
> > > BufferOverflowException is being thrown on that call to put(). The
> > > API says this is only thrown when the remaining size of theIntBuffer
> > > is less than the length of the int[] passed in. Well, both of those
> > > values are output to the log on the line just prior to calling put()
> > > (intBuf.remaining() and intArr.length). They both output 600, and
> > > last I checked 600 is not less than 600!
>
> > > I figure I am missing something simple. I checked the call made to
> > > allocateDirect() and it looks like this:
> > > -vertices_direct = ByteBuffer.allocateDirect (vertices.length *
> > > (Integer.SIZE >> 3));
> > > -vertices_direct.order (ByteOrder.nativeOrder ());
> > > -vertices_buffer = vertices_direct.asIntBuffer();
>
> > > The original code (using floating point math and Android SDK m3-rc37a)
> > > can be found
> > > here:http://www.enfis.it/wp-content/uploads/2008/01/tunnel3d.ziphttp://www...
>
> > > Obviously, I had to convert the original code up to Android SDK 1.0
> > > r2. I ended up using EGL as I did not see a way around it. Keep in
> > > mind I have little OpenGL experience, let alone ES 1.0 on Android.- Hide
> > > quoted text -
>
> > - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
