Thanks for the tip, but the dynamic nature of my app won't let me pre- compress the textures using PVRTC, or ATITC. I'll be loading icons, images, etc. that come from the user (think the Home/Launcher app for example) and AFAIK there's no way to do PVRTC compression at runtime, is there?
Thanks, Federico On Feb 1, 3:53 pm, Lance Nanek <lna...@gmail.com> wrote: > Hmm, for less texture data, but keeping some alpha, there are also the > options of: RGBA_5551; PowerVR Texture Compression (PVRTC); and > reducing the resolution of the texture, but still filling the screen > with it. Not all phones support PVRTC, however, so you have to check > for support and have a more compatible format ready as a fallback with > that option. Never tried any of the above myself. Maybe testing with a > 1x1 size texture to see the best speed for minimal texture data first > would be a good idea. > > On Feb 1, 7:10 am, Mario Zechner <badlogicga...@gmail.com> wrote: > > > > > 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?... > > read more » -- 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
