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/24d8d7e4f474c044/e9a452266364f889#e9a452266364f889 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
