Woops -- I left out a very important detail: Direct Buffers are only required for OpenGL ES APIs that hold onto the pointer that you pass into the API. APIs that operate on buffers immediately can take either direct or indirect buffers.
So, for example glVertexPointer requires a Direct buffer because it holds onto a pointer to the buffer until you call glVertexPointer with a different buffer. All the glXXXPointer APIs are like this. On the other hand, an API like glBufferData uses its buffer data immediately. So it's fine to use an indirect buffer with glBufferData. On Aug 5, 12:14 pm, 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 -~----------~----~----~----~------~----~------~--~---
