i'm working a prototype game that has a very similar setup to yours. I have a 2048x2048 big background texture which i load in 32-bit argb mode (i have yet to discover what format to use for 16-bit rgb 565, png doesn't support it, didn't care yet though). I split up this big thing into 256x256 pixel chunks for visibility culling so i only draw those chunks on screen. Additionally i have a second layer of 256x256 chunks in 16-bit rgba 4444 for which i also do culling. i have up to 1000 sprites on the screen, those are 12by12 pixels big. The sprites each consist of 2 triangles. All sprite triangles i write into a dynamic VBO each frame which is extremely fast to my surprise (write to temporary float array then pass that to the VBO). Everything is rendered in ortho mode using pixel perfect projection except for the sprites which use a lower mipmap level due to me still not sure on how big they should get. The two layers of background use linear filtering for both min and mag.
On my droid i get between 35-45fps, rendering and simulating the scene (and the simulation of the sprites takes quiet some time as it does pixel perfect collisions on a collision map of 2048x2048 bytes). On my hero i can get 60fps with the sprites turned of. The MSM7200 seems to have an optimization for axis aligned triangles in there that makes it blazingly fast. The droid gets around 50fps if i turn the sprites off. Note that i use 32-bit argb for the first layer which waste a lot of bandwidth and memory. The problem on the droid is sampling the texture. The portions of your quad that are not visible will of course not fetch any texels, try the following to see that effect: - let the quad fill the whole screen - the the quad fill 3/4 of the screen - let the quad fill 1/2 of the screen you only have 4 vertices to be transformed so you are clearly not transform bound. However, as you fill less and less space on the screen your framerate increases indicating that you are fillbound. For an ortho setup mipmapping won't help you as all texels will be fetched from the original size level 0. Linear filtering will also scrap some fps as you sample 4 textels for each pixel on screen. Nearest filtering might be the best option and will look as good as mipmapping (which is essentially linear filtering in your case) or linear filter as your quad is pixel perfect and screen aligned. Another way to reduce the texel fetch pressure is to use lower bit-depth textures, 16- bit argb4444 or rgb565 as less bytes have to go over the bus (if they do). There is simply no way on the droid to get around the fill rate issue. Switching to compatibility density mode which is around 540x320 pixels (from the top of my head this figure is for sure not correct) will get you another 2-3fps, but compared to the native screen res it looks worse and is not worth the extra fps. From this it is clear that the problem is probably not related to actually filling the framebuffer but only to fetching texels. To summarize: - use mipmapping for scaled down quads, nearest filtering for pixel perfect screen aligned quads - use 16-bit argb/rgb textures instead of 32-bit argb textures That's all you can do. The PowerVR in the droid is a beast and will happily transform as many vertices as you throw at it, i have yet to encounter an issue with that rendering stage. Fetching texels is expensive though so avoid it at all cost :) On 1 Feb., 07:22, Robert Green <rbgrn....@gmail.com> wrote: > The texture memory copy / fill bottleneck has been fairly consistent > across all chips so far. It's more pronounced on the MSM7200 chips > but is clearly still there. The good news is that while you might not > be able to get your upper FPS that you were hoping for, you probably > will be able to get a fairly good and stable framerate with a far more > complex scene. I was surprised at how no matter what I did, I > couldn't get my environment rendering over 40FPS with low res > textures, mipmap/nearest and no special effects, yet with a full scene > of monsters, HUD, multitextured environment, weapons, explosions, > fire, etc running with large textures with trilinear filtering on, I > got 30FPS. Crazy, huh? I think there is a LOT going on in terms of > optimizations and I wouldn't necessarily expect slowdown to be linear. > > On Jan 31, 10:14 pm, Federico Carnales <fedecarna...@gmail.com> wrote: > > > Hi Lance, > > > I doubt that's going to change much, I'm not doing any complex > > geometry or anything. Just to make sure, I removed the glClear, > > glActiveTexture, and glBindTexture calls from the draw method, and the > > performance is exactly the same. > > > The performance hit seems to come from using heavy textures, not from > > excessive GL calls or state changes. > > > Thanks, > > > Federico > > > On Feb 1, 12:52 am, Lance Nanek <lna...@gmail.com> wrote: > > > > If the final is only a non-transparent background and a couple > > > sprites, you may actually get it to perform slightly better than the > > > benchmark, not worse. The benchmark has a lot of extra stuff getting > > > called every frame. With a non-transparent background and drawing in > > > order, glClear isn't needed. If you only ever use the first texture > > > unit then then glActiveTexture call isn't needed. If all your > > > textures, the background and sprites, fit in one atlas texture then > > > the glBindTexture call isn't needed. If you use shared buffers then > > > the glVertexPointer and glTexCoordPointer calls aren't needed. All > > > those could be moved to only be called once instead of every frame if > > > those conditions are met. > > > > If you switch from triangle strips to triangles you can easily draw > > > the background and multiple sprites in a single draw command as well. > > > Degenerate triangles for connecting things might even work in triangle > > > strip mode. So the number of draw commands may not even go up. > > > > On Jan 31, 7:13 pm, Federico Carnales <fedecarna...@gmail.com> wrote: > > > > > Correction: using SurfaceView to draw the background image does indeed > > > > give me 60fps. And when adding the "sprites" on top of it, the > > > > performance is not 60fps anymore, but still better than GLSurfaceView. > > > > > Federico > > > > > On Jan 31, 9:09 pm, Federico Carnales <fedecarna...@gmail.com> wrote: > > > > > > Did the test you requested, RGB_565, mipmapped - nearest. Got 18ms/ > > > > > frame. Better, but still unacceptable as this would only be the > > > > > background image. The final app uses several sprites with alpha on top > > > > > of the background, so the performance drops significantly. > > > > > > What's funny is that I'm getting better performance with a regular > > > > > SurfaceView and CPU rendering. Not 60fps, but better than OpenGL's > > > > > performance. Something is seriously wrong there. > > > > > > Regards, > > > > > > Federico > > > > > > On Jan 31, 7:37 pm, Robert Green <rbgrn....@gmail.com> wrote: > > > > > > > I'd test it on my Droid but my graphics guy has it right now. I can > > > > > > try it out in a week or two when I get it back from him. > > > > > > > I think you may be video memory bound in some form. It sounds like > > > > > > it's sheer bytes slowing you down. Can you load the texture as > > > > > > RGB_565 mipmapped - nearest and give me a number? What about using > > > > > > glDrawTexiOES? I didn't realize you were trying to draw a 32 bit > > > > > > full > > > > > > screen image. I pretty much only draw 16 bit bitmaps when I can > > > > > > unless it's an effect or control and I need the alpha for that. > > > > > > > On Jan 31, 12:52 pm, Federico Carnales <fedecarna...@gmail.com> > > > > > > wrote: > > > > > > > > I've created a small sample class to show the problem: > > > > > > > >http://fedecarnales.googlepages.com/TextureTest.java > > > > > > > > It simply creates a full screen GLSurfaceView, sets up an > > > > > > > orthogonal > > > > > > > 2D matrix, creates a 1024x1024 texture from the default icon > > > > > > > file, and > > > > > > > displays it as a 480x854 quad on screen. The time-per-frame is > > > > > > > measured by counting the time it takes to render 100 frames, then > > > > > > > dividing it by 100 and writing it to the Logcat. > > > > > > > > On my Motorola Milestone, it's taking 34ms per frame, which is > > > > > > > outrageous. If I enable mipmapping it goes down to 20ms per frame, > > > > > > > which seems to indicate that the problem is directly related to > > > > > > > the > > > > > > > texture size or dimensions. > > > > > > > > What's interesting is that if you convert the bitmap to ARGB_4444 > > > > > > > before loading it as a texture, the rendering time goes down from > > > > > > > 34ms > > > > > > > to 24ms, which to me seems to show that it's a problem related to > > > > > > > the > > > > > > > size of the texture in bytes rather than the dimensions (although > > > > > > > the > > > > > > > dimensions will obviously change the byte size). > > > > > > > > Regards, > > > > > > > > Federico > > > > > > > > On Jan 31, 2:09 pm, Robert Green <rbgrn....@gmail.com> wrote: > > > > > > > > > Federico - are you using GLSurfaceView or did you init EGL > > > > > > > > yourself? > > > > > > > > If you initialized it yourself, did you check to make sure the > > > > > > > > config > > > > > > > > gave you 24 bits of depth and not 16? That would be one thing > > > > > > > > to > > > > > > > > cause the slowdown. > > > > > > > > > I usually get 40FPS on a Droid full-screen (not with a big quad > > > > > > > > but > > > > > > > > with a 3D scene) so something is certainly up with your code. > > > > > > > > > On Jan 31, 10:58 am, Lance Nanek <lna...@gmail.com> wrote: > > > > > > > > > > I don't have a Droid to test on, but if you haven't tried it > > > > > > > > > already, > > > > > > > > > it might be worth dropping the various texture settings down > > > > > > > > > to their > > > > > > > > > fastest/lowest quality and enabling mipmaps to check if > > > > > > > > > that's where > > > > > > > > > the problem is. Something like this: > > > > > > > > > > gl.glHint(GL10.GL_PERSPECTIVE_CORRECTION_HINT, > > > > > > > > > GL10.GL_FASTEST); > > > > > > > > > > if ( gl instanceof GL11 ) { > > > > > > > > > gl.glTexParameterf(GL11.GL_TEXTURE_2D, > > > > > > > > > GL11.GL_GENERATE_MIPMAP, > > > > > > > > > GL11.GL_TRUE);} > > > > > > > > > > gl.glTexParameterf(GL10.GL_TEXTURE_2D, > > > > > > > > > GL10.GL_TEXTURE_MIN_FILTER, > > > > > > > > > GL10.GL_NEAREST); > > > > > > > > > gl.glTexParameterf(GL10.GL_TEXTURE_2D, > > > > > > > > > GL10.GL_TEXTURE_MAG_FILTER, > > > > > > > > > GL10.GL_NEAREST); > > > > > > > > > > Some of the past threads have also stated that depth size 24 > > > > > > > > > is faster > > > > > > > > > than anything else on the Droid for some reason. So make sure > > > > > > > > > you end > > > > > > > > > up with that config. > > > > > > > > > > On Jan 30, 11:58 pm, Federico Carnales > > > > > > > > > <fedecarna...@gmail.com> wrote: > > > > > > > > > > > Hi all, > > > > > > > > > > > So I'm doing some simple 2D stuff with OpenGL on Android > > > > > > > > > > and found the > > > > > > > > > > performance to be very, very poor. > > > > > > > > > > > To give you an example, I made an app with a full screen > > > > > > > > > > GLSurfaceView. I loaded a 512x1024 texture (containing a > > > > > > > > > > 480x854 > > > > > > > > > > image), set up an orthogonal 2D matrix, and set it to draw > > > > > > > > > > a 480x854 > > > > > > > > > > pixel quad with that texture, using vertex and texture > > > > > > > > > > arrays. > > > > > > > > > > Lighting, dither, blending, etc. is disabled. > > > > > > > > > > > I would expect this to run at 60fps without problem, but > > > > > > > > > > that simple > > > > > > > > > > operation already drags the frame drawing time to > > > > > > > > > > 19ms/frame. > > > > > > > > > > > If I add some more small textured quads around the screen, > > > > > > > > > > the drawing > > > > > > > > > > time goes up to 22/24ms. If I enable blending it balloons > > > > > > > > > > to 28/30ms. > > > > > > > > > > > This is testing on a Motorola Milestone, running 2.0.1. > > > > > > > > > > > Is this normal? Am I doing something wrong or is it just a > > > > > > > > > > common > > > > > > > > > > problem in Android? > > > > > > > > > > > Any advice on how to attain 60fps drawing simple textured > > > > > > > > > > quads in 2D > > > > > > > > > > using OpenGL? > > > > > > > > > > > Thanks in advance! > > > > > > > > > > > Regards, > > > > > > > > > > Federico -- 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
