That's why you're supposed to load them all in one batch at the beginning and then not do it during runtime. glTexImage2D is one of the slowest things there is on any chip. If you're targeting ES2.0, you have things like framebufferobjects that you can use to handle dynamic texturing using the GPU and those are blazing fast.
What's your application? Why do you need a texture update every draw? Perhaps there is a totally different way you can go about it. On Apr 16, 1:11 pm, Eong <[email protected]> wrote: > I use glTexImage2D and glTexSubImage2D, it's okay on Droid/Milestone. > 20ms for 854*480. > But on Nexus one, it takes 150ms to draw a full screen.(800*480) > > On 4月16日, 下午7时39分, Mario Zechner <[email protected]> wrote: > > > > > > > From my experience this also happens with the PowerVR chips in the > > Droid/Milestone > > > On 16 Apr., 13:07, Eong <[email protected]> wrote: > > > > IfglTexImage2Dis more than 100ms, glTexSubImage2D doesn't make any > > > sense. > > > I found that this will only happen on phones with snapDragon chips, > > > like Nexus one, Liquid and so on. > > > I tried a lot, can't solve it yet. > > > > On 2月24日, 下午5时19分, Ralf Schneider <[email protected]> wrote: > > > > > 2010/2/24 Jonathan <[email protected]> > > > > > > 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? > > > > > You can try: glTexSubImage2D > > > > <http://www.khronos.org/opengles/documentation/opengles1_0/html/glTexS...>instead > > > > ofglTexImage2D. Usually this function is the right choice to update > > > > textures frequently. > > > > > glTexSubImage2D may have the advantage to not require the OpenGL Es > > > > memory > > > > management system, because an existing texture (memory area) gets > > > > updated. > > > > > Furthermore some OpenGL ES implementation implicit convert textures to > > > > one > > > > of its internal formats. For example the implementation may convert all > > > > textures to 565 or 4444 regardless of the format you provide. > > > > Thus, if you provide textures in an native format the implementation > > > > could > > > > do a plain copy of the data, instead of a more expensive conversion. > > > > > ... But i have no real data available. These are just general advices > > > > floating in the intertubes. > > > > > Regards, > > > > Ralf > > > > -- > > > 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 > > > athttp://groups.google.com/group/android-developers?hl=en > > > -- > > 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 > > athttp://groups.google.com/group/android-developers?hl=en > > -- > 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 > athttp://groups.google.com/group/android-developers?hl=en -- 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
