[android-developers] Re: OpenGL poor performance with textures?
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 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 argb 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
[android-developers] Re: OpenGL poor performance with textures?
Hi Federico,
I tried during weeks to get a working code for the opengles. The idea
was to draw an offscreen bitmap into the screen (i do all the graphics
rendering by myself). Then someone told me that using textures for
this was not a good idea, because it takes time to make the texture
get into the video card and then displayed.
Since my knowledge of opengl is near 0, i gave up and used the
SurfaceView approach. I also published the code here:
This goes at surfaceChanged:
sScreenBuff = ShortBuffer.allocate(w * h);
sScreenBitmap = Bitmap.createBitmap(w, h,
Bitmap.Config.RGB_565);
And this is my updateScreen method:
static void updateScreen()
{
try
{
if (sScreenBitmap == null)
return;
Canvas canvas = surfHolder.lockCanvas();
if (canvas == null)
return;
instance.nativeOnDraw(sPixels); // call Native C code
sScreenBuff.put(sPixels);
sScreenBuff.rewind();
sScreenBitmap.copyPixelsFromBuffer(sScreenBuff);
canvas.drawBitmap(sScreenBitmap, 0, 0, null);
surfHolder.unlockCanvasAndPost(canvas);
}
catch (Throwable t)
{
debug(Log.getStackTraceString(t));
}
}
Have you done something different to achieve the 60fps?
Btw, i can test your code in two devices, the G2 Ion and the Motorola
Milestone (A853).
thanks and regards,
guich
--
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
[android-developers] Re: OpenGL poor performance with textures?
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 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 argb 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
[android-developers] Re: OpenGL poor performance with textures?
Hi Mario, Thanks for the info! So basically, there's no way to draw a 480x854 image on screen with OpenGL at 60fps because of the texel reading bottleneck. Bummer :( I think the PowerVR chip is actually capable of doing it, but Android is actually fetching the pixels/texels twice. Once when you render your OpenGL scene, and again when the SurfaceFlinger composes the screen. Am I right? Is there any way to bypass the SurfaceFlinger if you're running a full screen app? No composition is needed since the entire screen is used by the OpenGL context, so there's no reason to render the pixels twice. Thanks again, Federico On Feb 1, 9: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 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 argb 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
[android-developers] Re: OpenGL poor performance with textures?
Hi Guich,
I didn't do anything special to achieve 60fps with a SurfaceView, just
get a lock to the surface and draw the bitmap onto the canvas. Mind
you, I only get 60fps when drawing a static, full screen bitmap to the
SurfaceView. If I draw more bitmaps on top of that background bitmap,
the FPS goes down.
Regards,
Federico
On Feb 1, 12:29 pm, guich guiha...@gmail.com wrote:
Hi Federico,
I tried during weeks to get a working code for the opengles. The idea
was to draw an offscreen bitmap into the screen (i do all the graphics
rendering by myself). Then someone told me that using textures for
this was not a good idea, because it takes time to make the texture
get into the video card and then displayed.
Since my knowledge of opengl is near 0, i gave up and used the
SurfaceView approach. I also published the code here:
This goes at surfaceChanged:
sScreenBuff = ShortBuffer.allocate(w * h);
sScreenBitmap = Bitmap.createBitmap(w, h,
Bitmap.Config.RGB_565);
And this is my updateScreen method:
static void updateScreen()
{
try
{
if (sScreenBitmap == null)
return;
Canvas canvas = surfHolder.lockCanvas();
if (canvas == null)
return;
instance.nativeOnDraw(sPixels); // call Native C code
sScreenBuff.put(sPixels);
sScreenBuff.rewind();
sScreenBitmap.copyPixelsFromBuffer(sScreenBuff);
canvas.drawBitmap(sScreenBitmap, 0, 0, null);
surfHolder.unlockCanvasAndPost(canvas);
}
catch (Throwable t)
{
debug(Log.getStackTraceString(t));
}
}
Have you done something different to achieve the 60fps?
Btw, i can test your code in two devices, the G2 Ion and the Motorola
Milestone (A853).
thanks and regards,
guich
--
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
[android-developers] Re: OpenGL poor performance with textures?
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 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 argb 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
Re: [android-developers] Re: OpenGL poor performance with textures?
Hey all, maybe I am way off base on this.. but I recall years ago messing
around with writing data to an off-screen buffer, then flipping the buffer
to video ram. I am guessing this is no longer done.. or is it? I thought the
reason for that years ago was it was much faster to write multiple layers of
a graphics scene, like side scrollers, even 3D scenes, in some off-screen
vram (or even regular memory), then swap the whole thing to the video ram
and doing that 30+ times a second yielded good performance. I apologize if
this is not how it's done any longer.. just wondering if that is still an
option and would help, or if that is so old school it's no longer ever done?
On Mon, Feb 1, 2010 at 11:56 AM, Federico Carnales
fedecarna...@gmail.comwrote:
Hi Guich,
I didn't do anything special to achieve 60fps with a SurfaceView, just
get a lock to the surface and draw the bitmap onto the canvas. Mind
you, I only get 60fps when drawing a static, full screen bitmap to the
SurfaceView. If I draw more bitmaps on top of that background bitmap,
the FPS goes down.
Regards,
Federico
On Feb 1, 12:29 pm, guich guiha...@gmail.com wrote:
Hi Federico,
I tried during weeks to get a working code for the opengles. The idea
was to draw an offscreen bitmap into the screen (i do all the graphics
rendering by myself). Then someone told me that using textures for
this was not a good idea, because it takes time to make the texture
get into the video card and then displayed.
Since my knowledge of opengl is near 0, i gave up and used the
SurfaceView approach. I also published the code here:
This goes at surfaceChanged:
sScreenBuff = ShortBuffer.allocate(w * h);
sScreenBitmap = Bitmap.createBitmap(w, h,
Bitmap.Config.RGB_565);
And this is my updateScreen method:
static void updateScreen()
{
try
{
if (sScreenBitmap == null)
return;
Canvas canvas = surfHolder.lockCanvas();
if (canvas == null)
return;
instance.nativeOnDraw(sPixels); // call Native C code
sScreenBuff.put(sPixels);
sScreenBuff.rewind();
sScreenBitmap.copyPixelsFromBuffer(sScreenBuff);
canvas.drawBitmap(sScreenBitmap, 0, 0, null);
surfHolder.unlockCanvasAndPost(canvas);
}
catch (Throwable t)
{
debug(Log.getStackTraceString(t));
}
}
Have you done something different to achieve the 60fps?
Btw, i can test your code in two devices, the G2 Ion and the Motorola
Milestone (A853).
thanks and regards,
guich
--
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.comandroid-developers%2bunsubscr...@googlegroups.com
For more options, visit this group at
http://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 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
[android-developers] Re: OpenGL poor performance with textures?
Hi,
If you are using surfaceview I believe it does backbuffer flipping for
you
-niko
On Feb 1, 2:00 pm, Kevin Duffey andjar...@gmail.com wrote:
Hey all, maybe I am way off base on this.. but I recall years ago messing
around with writing data to an off-screen buffer, then flipping the buffer
to video ram. I am guessing this is no longer done.. or is it? I thought the
reason for that years ago was it was much faster to write multiple layers of
a graphics scene, like side scrollers, even 3D scenes, in some off-screen
vram (or even regular memory), then swap the whole thing to the video ram
and doing that 30+ times a second yielded good performance. I apologize if
this is not how it's done any longer.. just wondering if that is still an
option and would help, or if that is so old school it's no longer ever done?
On Mon, Feb 1, 2010 at 11:56 AM, Federico Carnales
fedecarna...@gmail.comwrote:
Hi Guich,
I didn't do anything special to achieve 60fps with a SurfaceView, just
get a lock to the surface and draw the bitmap onto the canvas. Mind
you, I only get 60fps when drawing a static, full screen bitmap to the
SurfaceView. If I draw more bitmaps on top of that background bitmap,
the FPS goes down.
Regards,
Federico
On Feb 1, 12:29 pm, guich guiha...@gmail.com wrote:
Hi Federico,
I tried during weeks to get a working code for the opengles. The idea
was to draw an offscreen bitmap into the screen (i do all the graphics
rendering by myself). Then someone told me that using textures for
this was not a good idea, because it takes time to make the texture
get into the video card and then displayed.
Since my knowledge of opengl is near 0, i gave up and used the
SurfaceView approach. I also published the code here:
This goes at surfaceChanged:
sScreenBuff = ShortBuffer.allocate(w * h);
sScreenBitmap = Bitmap.createBitmap(w, h,
Bitmap.Config.RGB_565);
And this is my updateScreen method:
static void updateScreen()
{
try
{
if (sScreenBitmap == null)
return;
Canvas canvas = surfHolder.lockCanvas();
if (canvas == null)
return;
instance.nativeOnDraw(sPixels); // call Native C code
sScreenBuff.put(sPixels);
sScreenBuff.rewind();
sScreenBitmap.copyPixelsFromBuffer(sScreenBuff);
canvas.drawBitmap(sScreenBitmap, 0, 0, null);
surfHolder.unlockCanvasAndPost(canvas);
}
catch (Throwable t)
{
debug(Log.getStackTraceString(t));
}
}
Have you done something different to achieve the 60fps?
Btw, i can test your code in two devices, the G2 Ion and the Motorola
Milestone (A853).
thanks and regards,
guich
--
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.comandroid-developers%2Bunsubs
cr...@googlegroups.com
For more options, visit this group at
http://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 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
[android-developers] Re: OpenGL poor performance with textures?
@Kevin I can easily see wheter something runs at 30 or 60fps. http://www.gamasutra.com/blogs/RadekKoncewicz/20100106/4021/Framerates_Do_Matter.php is an interesting article on the matter @Federico The thread over at http://groups.google.com/group/android-developers/browse_thread/thread/57afe5120c24c371# might be intersting for you. On 31 Jan., 07:55, Kevin Duffey andjar...@gmail.com wrote: I am curious..why do you need 60fps? 30fps is smooth motion to the human eye. I've seen that posted a few times now and fail to understand why 60fps is needed? Of course, I understand doing 30fps would be nice, but if I could yank more out of my game and sustain 30fps, I'd rather do that. On Sat, Jan 30, 2010 at 8:58 PM, Federico Carnales fedecarna...@gmail.comwrote: 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.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://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 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
[android-developers] Re: OpenGL poor performance with textures?
@Kevin Just like Mario, I can easily tell between 30 and 60fps, it makes a world of difference to me. I'm only going to be drawing simple 2D quads, no complex geometry, so 60 fps is very important to me. Anyway, the question is not whether I need 60 fps or not, the question is: Is the PowerVR SGX in the Motorola Milestone not capable of sustaining 60fps for such simple operations, or is it a software issue (like Android's implementation of OpenGL, or something in the SurfaceFlinger) ? @Mario Yeah, I read the entire thread but couldn't find any conclusions as to why that was happening? Also, the thread seems mostly focused on the framerate slowdown when the screen is touched. I'm seeing slowdown just by drawing one textured quad on screen (though it gets even slower if I touch the screen) :( Thanks again, Federico On Jan 31, 3:55 am, Kevin Duffey andjar...@gmail.com wrote: I am curious..why do you need 60fps? 30fps is smooth motion to the human eye. I've seen that posted a few times now and fail to understand why 60fps is needed? Of course, I understand doing 30fps would be nice, but if I could yank more out of my game and sustain 30fps, I'd rather do that. On Sat, Jan 30, 2010 at 8:58 PM, Federico Carnales fedecarna...@gmail.comwrote: 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.comandroid-developers%2Bunsubs cr...@googlegroups.com For more options, visit this group at http://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 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
[android-developers] Re: OpenGL poor performance with textures?
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
[android-developers] Re: OpenGL poor performance with textures?
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
[android-developers] Re: OpenGL poor performance with textures?
Hi Lance,
Yes, already tried using mipmaps, and every possible combination of
min and mag filters. Still can't sustain 60fps with one fullscreen
textured quad. I checked GL_DEPTH_BITS and it's properly set to 24.
Thanks,
Federico
On Jan 31, 1:58 pm, 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
[android-developers] Re: OpenGL poor performance with textures?
Hi Robert,
I'm using GLSurfaceView. I checked GL_DEPTH_BITS and indeed I have a
24 bit depth buffer.
Since you have a Droid, could you do me a favor? Could you make a
simple app with nothing but a GLSurfaceView, load a 1024x1024 texture
(I'm actually using 512x1024, but 1024x1024 should show the problem
better) and display it in a full screen quad? If you can get 60fps
then there's something definitely wrong with my code.
It seems to me that there's a bottleneck somewhere when using
textures, because if I use a small texture and put it in a full screen
quad, I get 60fps no problem. It's when I use a larger texture that
the framerate starts dropping.
Does the Droid/Milestone have dedicated video RAM? Or is it shared
system RAM? If it's shared, could the bottleneck be in transferring
the big texture to the GPU on every frame?
Thank you,
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
Re: [android-developers] Re: OpenGL poor performance with textures?
Droid has dedicated video ram I believe. Not sure about other devices. I
would guess the Nexus One does as well.
On Sun, Jan 31, 2010 at 9:54 AM, Federico Carnales
fedecarna...@gmail.comwrote:
Hi Robert,
I'm using GLSurfaceView. I checked GL_DEPTH_BITS and indeed I have a
24 bit depth buffer.
Since you have a Droid, could you do me a favor? Could you make a
simple app with nothing but a GLSurfaceView, load a 1024x1024 texture
(I'm actually using 512x1024, but 1024x1024 should show the problem
better) and display it in a full screen quad? If you can get 60fps
then there's something definitely wrong with my code.
It seems to me that there's a bottleneck somewhere when using
textures, because if I use a small texture and put it in a full screen
quad, I get 60fps no problem. It's when I use a larger texture that
the framerate starts dropping.
Does the Droid/Milestone have dedicated video RAM? Or is it shared
system RAM? If it's shared, could the bottleneck be in transferring
the big texture to the GPU on every frame?
Thank you,
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.comandroid-developers%2bunsubscr...@googlegroups.com
For more options, visit this group at
http://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 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
[android-developers] Re: OpenGL poor performance with textures?
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_
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
[android-developers] Re: OpenGL poor performance with textures?
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_
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
[android-developers] Re: OpenGL poor performance with textures?
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_
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
[android-developers] Re: OpenGL poor performance with textures?
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_
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!
[android-developers] Re: OpenGL poor performance with textures?
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_ 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 )
[android-developers] Re: OpenGL poor performance with textures?
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_ 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
