By the way, to guarantee that non-direct buffer will not be moved be GC one can hack up a JNI lib wich will 'pin' needed buffers for the lifetime of an application :)
On 6 авг, 10:07, "Dmitry.Skiba" <dmitry.sk...@gmail.com> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
