Thank you Jack for your explanation. I am using VBOs now, so I can easily switch to direct buffers. By the way, what is the limit for VBO buffers? (if there is one)
And one more thing. In my code I am drawing a 1008-vertex geometry using glDrawArrays(GL_TRIANGLES). Weird thing is that it draws model + garbage when I pass 1008 as 'count' argument to glDrawArrays, and draws correctly when I pass 1008/3. I believe 1008 is the correct value to pass, but it just not working that way. In many demos there are calls to glDrawArrays with GL_TRIANGLES, but they only draws few vertices (36 for example). I suspect my 1008 vertices (and normals) do not fit in some sort of cache, and code draws them differently, and somewhere it multiplies 'count' by 3 (hence drawing garbage when 1008 is passed). This behaviour shows up on the emulator and the G1. (glDrawElements has the same behaviour when indices are simple array [0,count-1].) Dmitry On 6 авг, 02:14, Jack Palevich <jack.palev...@gmail.com> wrote: > Hi -- I work on the Java Open GL ES bindings for Android. Fadden asked > me to chime in here. > > Please don't use indirect buffers with OpenGL ES -- indirect buffers > are not supported, and your code will break, both on current and > especially on future versions of Android. > > Let me see if I can explain what's going on: > > (In my message below I'm going to use the code-name "Cupcake" for the > current Android release and the code-name "Donut" for the upcoming > release.) > > There are several bugs in the way Android currently handles > java.nio.Buffer objects passed to OpenGL ES APIs: > > 1) In all releases up to and including Cupcake, the implementation > allocates "PlatformAddress" objects every time a direct buffer's base > address is calculated. (In other words, when any glXXXPointer function > is called.) This leads to garbage collections, even in programs that > don't appear at the API level to be allocating any new objects. (You > can use a heap analysis tools to watch these PlatformAddress objects > being created.) > > 2) The OpenGL ES APIs that take buffers are only supposed to take > direct buffers, but this runtime check was accidentally omitted from > all releases up to and including Cupcake. The problem with non-direct > buffers is that their data can be moved by the Java runtime while the > OpenGL driver is holding a pointer to them, which means that OpenGL > driver ends up reading the wrong data, or even trying to read no- > longer-allocated memory. > > To fix problem #2, the Donut system software release will start > enforcing the direct buffer requirement. To keep existing, mostly- > working OpenGL applications from breaking, we are going to add a > "compatibility shim" in Donut: If your application is compiled against > the Cupcake or earlier SDK, then we won't throw an exception if you > use a non-direct buffer with OpenGL ES. You app will still suffer from > the same "occasionally crashes or renders incorrectly" bug that it > currently suffers from under Cupcake, but things won't be any worse. > We will print out an error message to the log so at least you have a > way of detecting that your app is using OpenGL incorrectly. > > If your application is compiled with the Donut SDK, it will throw a > runtime exception if you try to use a non-direct buffer with an OpenGL > ES API. (The reasoning is that if you are compiling using the Donut > SDK, then you can take the time to fix your app.) > > OK, so what's a poor developer to do now, before the Donut system > software? > > You could try using indirect buffers, in which case you will get code > that doesn't GC very much, but also occasionally renders incorrectly > or crashes. Or you can use direct buffers, and live with more GCs. > > I recommend using direct buffers, because I think it's better to have > occasional GC hiccups than crashes. And once Donut is released the GC > disadvantage should be fixed. > > On Aug 5, 11:01 am, fadden <fad...@android.com> wrote: > > > On Aug 4, 11:09 pm, "Dmitry.Skiba" <dmitry.sk...@gmail.com> wrote: > > > > I've found a way to get rid of garbage collection! > > > The receipt is simple (and ironic): do not use allocateDirect(), use > > > allocate(). And use only ByteBuffer, not FloatBuffer, IntBuffer, etc. > > > - using asFloatBuffer() on non-direct ByteBuffer will result in crash > > > in libhgl. (I'm too lazy to create an issue for that.) > > > I'm pretty sure this will break in the next release. My (very > > limited) understanding is that direct buffers are supposed to be > > required, but Android wasn't enforcing their use. This situation has > > been corrected. > > > The allocations reduced by 8767 (earlier in the thread) were Harmony > > PlatformAddress objects, which are only associated with direct > > buffers. So it makes sense that your change would cut the > > allocations; just be aware that it may stop working. > > > (I'll ask one of the GL folks to check me on this.) > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
