So, I've been a good boy (I think) and used ByteBuffers (and ShortBuffers and IntBuffers etc) for all the vertex lists and textures I feed to GLES.
But can someone point me to the basic architecture of the 'typical' mobile GPU (or, I guess, the OpenVR Droid GPU at least). For example, does a mobile GPU have its own texture/buffer memory, or does it always share 'system memory' ? If it's going to copy the data I give it into 'gpu ram' anyway, then have I just added another buffer in the bucket brigade of memory when I use a ByteBuffer? GLES seems perfectly happy using a direct java array for the data, but I imagine that does nasty things like locking memory when the GPU touches it, when maybe memory outside the garbage collection heap doesn't have that problem (and just gets leaked when I mis-manage it :-) I can't say that I see any performance difference between using ByteBuffers or just direct java arrays. But most of my meshes (and all of my textures) are created just once. But some meshes (for example, particles) get regenerated every frame. And for that, I do the math in a java array and then allocateDirect a suitable <whatever>Buffer before passing it to GLES. That smells really awful to me and I guess I am just wondering how big a sin it would be to not use <whatever>Buffers for these dynamic meshes? I guess I just feel like I am flying blind without some GPU documentation to look at. -- 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