I'm testing on an N1 at the moment. glTexImage2D works great on the iPhone, but I think you're right, it's not gonna fly with Android.
Does OpenGL still offer the best 2D performance over the alternatives (ie: canvas drawing, etc)? Thanks a lot for your help! On Feb 23, 11:38 pm, Robert Green <[email protected]> wrote: > Are you using a device or an emulator? The emulator is notoriously > slow at texture uploads. You need to test on real devices to know > what kind of real-world performance you'll get. > > This question has come up many times and the answer seems to be: > glTexImage2D is pretty slow on most chips. Find a better way (such as > framebuffers) or don't try to upload so much data. > > Here is a thread that you should read through to save yourself lots > and lots of time > -http://groups.google.com/group/android-ndk/browse_thread/thread/24d8d... > > Here are some numbers from the post: > 256x256 => mid 30s > 512x256 => high 60s (with a jump to 100+?) > 256x512 => high 60s > 512x512 => 130-150 > So they seem to scale appropriately. > > On Feb 23, 10:25 pm, Jonathan <[email protected]> wrote: > > > > > I have an array in memory that represents the screen. I then call > > put() once to put that into the ByteBuffer that gets pased to OpenGL. > > > I tried skipping the ByteBuffer stuff and just passing the internal > > array from Java to native and then calling glTexImage2D() with the > > pointer to avoid the copy, and while it's slightly faster, the upload > > of the texture takes about 100ms which is too long. > > > It's a 2D application, and the contents of the "screen" (as > > represented by this internal array I'm passing around) can change at > > any given time. I'm think I may have to use some combination of sub > > texture updates in order to get what want and have it be smooth. > > Uploading a 512x256 texture each frame may be too much. > > > Any other ideas how I can speed this up? > > > On Feb 23, 6:42 pm, Robert Green <[email protected]> wrote: > > > > If you're creating a bitmap dynamically, writing one byte at a time > > > with .put(), I wouldn't be surprised at all if it's really slow. If > > > at all possible, move that code into native. You can preallocate a > > > ByteBuffer in Java, pass it into native and work on the pointer > > > directly in native, then use it in OpenGL either in Java or in > > > native. > > > > You haven't said what the application is but if you can use the GPU > > > and a framebuffer to create your dynamic texture instead of doing it > > > on the CPU with a bitmap, that's another much faster way to go. > > > > On Feb 23, 5:42 pm, Jonathan <[email protected]> wrote: > > > > > Hey guys, > > > > > I'm porting over some software from the iPhone, and the fact that I > > > > need to use ByteBuffers for my data structures in order to use OpenGL > > > > is killing me. My render loop takes 3ms to actually do the work and > > > > render screen, but I do need to perform a ByteBuffer clear / > > > > repopulate to update a dynamic texture. > > > > > The bytebuffer clear, followed by the put() and position(0) to prepare > > > > for texture uploading takes about 100ms. This is WAY too slow. > > > > > Is there a way around using ByteBuffers other than going the NDK > > > > route? The texture is 512x256 RGBA... should the > > > > ByteBuffer .clear() .put() and .position() be taking 100ms? > > > > > Thanks in advance. -- 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
