The MSM7200 contains many optimizations to make certain types of filling fast. I never run full screen, 512 textures with linear min and mag on like you have in your code. Try it with nearest neighbor on both and see how it goes.
On Mar 1, 3:10 am, Michele Scorcia <michele.scor...@gmail.com> wrote: > Hi, > > I've found that if I rotate a square textured with a 512x512 texture > by 90 degrees, the frame rate goes from 60 fps in the case of the 0 > degrees rotation to 8 fps in case of the 90 degrees rotation. Just to > be clear the difference between the two cases is just a value of 0 or > 90 for angle in the gl.glRotatef(angle, 0, 0, 1) method inside the > drawing method. > > I noticed this behaviour on the HTC G1, HTC Magic and the Samsung > i7500 Galaxy that all share the same or really similar hardware, but > not on the Nexus One. > > I really draw the square 4 times to make the behaviour more evident. > > At the following links you can find the apk and the Eclipse project of > a test application that shows the behaviour: > > http://web.tiscali.it/scorcia/TextureTest.apk > > http://web.tiscali.it/scorcia/TextureTest.tar.gz > > In the application you can see the square and the frame rate and you > can rotate the square by moving the trackball/dpad left/right. > Moving it up/down you can pass from a single square with a texture of > 512*512 px to 16 squares with textures of 128*128 px that occupy the > same surface. I've done this to test the influence of the texture size > on the behaviour and in this case the frame rate goes from 40fps at 0° > (the code to draw the 16 squares is not optimized) to 14 at 90°. This > seems to point out that with smaller texture size the problem is a > little less evident. > Always using the application you can notice that just rotating the > square by 10° the frame rate goes from 60 to 40 and at 45° it's > already 12. > > Did anybody find this kind of behaviour before? > Naturally I can not exclude that I've done something wrong in the > sample application but it doesn't seem to me. > > I understand that the hardware that shows this behaviour is not so > recent but I think that if this behaviour is confirmed it worth to > understand what can be the cause of it and if it can be fixed in some > way because trying to optimize some OpenGL code when a simple rotation > can have this effect is a little bit difficult. > > My hypothesis is that it isn't a platform problem but maybe a opengl > driver problem or a hardware limitation (I hope it's not). Maybe > something related to a not optimal reading of texture data from memory > when it's read by columns instead that by rows. > > Thank you > Michele -- 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
