I have made an app which works well on iOS but has performance problems on Android. I have noticed that on older devices such as galaxy s2 with a low screen resolution, the app is fine. It only lags on the new hd devices such as the galaxy s4 and nexus 4.
Are high screen resolutions causing the devices to lag?
Does anyone know what I can do to find out how to fix this?
It's really strange because it's only on the new devices.
Not sure why it is happening on the S4 since it has a decent CPU and GPU, but high-density screens will cause lag, especially in Flash-based apps. I ran into the same problems when trying to move from the iPad 2 to the retina displays.
Let's look at it this way, with regards to the iPad issue I had. The iPad 3 bumped the resolution from 1024x768 to 2048x1536. That is 4x as many pixels. Traditionally, Flash has issues rendering vector images. It is good at it, among the best, but it is slow. So rendering a vector object on the iPad 2 was only a 40x40 area to update. On the iPad 3, it is a 160x160 area to update.
Quick tips:
Never use CPU rendering. Stick to Direct (or GPU if you need to, but you lose features with GPU rendering, such as filters)
Decrease the amount of vectors being used and how often you are changing them. You should avoid, at all costs, updating vector objects every frame.
Make sure you are testing a release build (In Flash Builders, Project->Export Release Build...) when testing framerate issues. It is generally much more evident on the iOS side than the Android side, but debug builds do cause lag
Don't set the framerate higher than you have to. As the framerate goes higher, each frame has less time to run the necessary calculations. The lag you notice isn't truly from low framerates (though that doesn't help), but more from dropped frames when a frame takes longer than available to render. 24 is the default, 30 is the standard. 60 is the max and is always nice, but it is completely unnecessary unless you are making a game.
I have several apps in production right now that run just fine on my Nexus 5, which is the same resolution as the S4 with roughly the same hardware, spec-wise. Unless there is a problem with that hardware specifically, you should be able to manage 30fps no problem, if not 60.
use direct render mode it is recommended by adobe.
Related
I'd like to know, how can I select the best resolution to build a 2D game in android?
You can go with 1920*1080 - this will give you a clear output on most current devices - and use FitViewPort or ExtendViewPort as you wish.
I'm rendering my graphics in 2K resolution (i.e. in 3040 x 1,40 - aiming most popular high-end phones of today, i.e. Samsung S10) so it will definitely look well on screens with higher resolution. And then I'm using camera zoom to display it properly on current screen resolution. It does take a bit more space for graphics and it's probably loosing some frame per second but on today's devices it's acceptable loss. My games run smooth even on older devices, so I don't think it's an issue at all.
I use SurfaceView for my 2D Android game which I have almost completed. It's based on JBox2D. It is perfectly running on Samsung Galaxy S2, its FPS is 60. It is also running smoothly on HTC Explorer, its FPS is about 54. I thought that if my game was working well in these relatively old devices, it would be working better in the newer ones. But I was wrong! I saw yesterday the FPS value of my game on Galaxy Note 4 is varied between 22 and 45 depending on the number of game objects.
After investigating on this issue in Google and StackOverflow, I deduced that the new devices like Galaxy Note 4 which has higher resolutions (1440 x 2560) could not handle with their large images whereas the little ones can handle with their own smaller images (Galaxy s2:480 x 800, HTC Explorer:320 x 480). Yes, the new devices are surely faster than the older ones, but I think their huge resolutions of the newer devices are the reason of the slowness on the SurfaceView. Of course, this is valid under SurfaceView conditions. If I used OpenGL for my game, it would not be a problem for the new devices having high resolutions.
My bitmaps are designed for 800 x 1280 devices. According to the different device resolutions, my game rescales the images when they are loaded at the beginning of the each level by using createScaledBitmap.
I couldn't transform my game from SurfaceView to OpenGL platform because my game is about to finish and I didn't have enough knowledge about OpenGL.
What should I do?
I believe you have correctly identified the problem: newer devices have pixel counts like you'd find on a 27" monitor (2560x1440), because the manufacturers are chasing screen resolution like they do camera megapixels. The result is that rendering a full screen takes longer, especially when you're doing it in software. Faster CPUs and increased bus bandwidth can help, but full-screen software rendering is problematic.
The solution for Android is to make the Surface smaller, and let the hardware scale it up as it's being scanned out. This is significantly easier (and more efficient) than scaling up each individual item. You do this with the SurfaceHolder#setFixedSize() method. For example, for a 2560x1440 display, you could set the Surface size to 1280x720, and only render a quarter of the pixels. The display performs the pixel doubling (with bilinear filtering).
You can find a blog post here, and can see this in action in Grafika's "hardware scaler exerciser" activity (youtube demo video).
The various examples use GLES -- which also benefits from having fewer pixels to fill -- but applies to Canvas rendering as well.
I am working with AndEngine and OpenGL ES 2.0. I keep reading about GL_MAX_TEXTURE_SIZE and how I should keep my texures under 1024x1024. I started wrong before and while using tilesets in TMX extension (doesn't really matter what it is, if you don't know AndEngine) I get to a tileset that makes a texture wider than 1024px. I am thinking of splitting the tileset into two, making them "safe". But I can't find any device released in last couple of years that has this limit set under 2048x2048. Is there any list or website I can use to filter devices by GL_MAX_TEXTURE_SIZE?
I read the following questions:
Minimum required Texture Size for compliance with OpenGL-ES 2.0 on Android?
Is there any Android device with screen size greater than GL_MAX_TEXTURE_SIZE?
And I used this site to search for devices. But I can't search by/filter by GL_MAX_TEXTURE_SIZE, which makes the search tedious. I am asking mostly because I started wrong, it's a hobby project and the amount of work might be too large compared to the number of possible devices that will be enabled (I expect 0).
1024x1024 is about the safest you can go on any device, especially on older ones. Newer devices shouldn't have any problem, although I've seen recent devices (I recall a Galaxy Nexus, the newest ICS update fixed that though) render white quads with texture sizes of size 2048x1024.
If you're targeting new devices and want to keep older ones compatible, it shouldn't hurt to split your tilesets. After all, you aren't likely to do too many context switches if you use two or three spritesheets for background, etc.
If you still have the individual image files, breaking them into small sized Atlases or custom sized atlases is easy if you use the TexturePacker2 tool from the LibGdx library.
I don't know the exact limitation of devices, but it's always better to take into consideration the lowest end of device you want to support and build upward from there. Using the LibGdx tool, you can easily change your mind later, so it's the most flexible solution.
Look at:
LibGdx TexturePacker
I'm developing an app that does live filtering of the camera preview stream ON THE GPU (OpengGL ES 2.0). It's similar to the famous apps "paper camera" (paid) and "cartoon camera" (free).
It works fine and quite fast on my galaxy s2, even faster on an s3 and ok on older Samsung devices. I've also tested it on a Sony Xperia Arc S and htc desire, as well as on several other devices I don't remember, where it isn't quite as fast as on my s2 but at least above 10 fps.
NOW HERE'S THE PROBLEM:
Yesterday I was able to test it on a HTC One X+ and a Galaxy Tab 10.1 (tegra 3 and tegra 2 respectively). On the one x+ it runs at around 5 fps and on the tablet at about 2 fps.
I also tried the before mentioned similar apps (paper camera and cartoon camera) on the one x+ where they also run considerably slower compared to my galaxy s2, even though they SHOULD run faster because of better hardware.
Is there any known problem of tegra GPUs concerning texture upload speed (I have to create a texture for every video frame) or something else that could reduce speed that much?
PS: Reducing camera preview resolution makes it slightly faster, but its still annoyingly slow.
Probably the issue is on the fragment shader itself, I've worked quite a lot with shaders on different GPU's and I've allways have found that not a faster GPU means a faster interpretation of the shader.
Are you using a lot of branching in you fragment shader ('if' conditions), or calls to other functions within the shader? If so, then you should try to avoid branching, also to inline the code's function into one, and to test GLSL built in functions which might be buggy on the current gpu drivers implementation, and then write your own replacement.
My Android app has been out for several months and works fine on any number of WVGA phones like the Droid, Droid 2, Galaxy, etc.
On the Motorola Xoom, however, a small portion of the textures load with white boxes where the images should be.
Researching online the most usual cause for this appears to be not using power of two textures. This seems an unlikely explanation since they work fine on so many other devices. Also, I am using power of two textures. The one caveat there is that I'm loading a bunch of bitmaps into a 1024 by 1024 texture dynamically. The code I'm using is from a now defunct library called Rokon, the relevant texture atlas code is here: http://code.google.com/p/rokon/source/browse/trunk/src/com/stickycoding/rokon/TextureAtlas.java?r=260 -- Like I said, I'm skeptical this could be the cause since it works on so many other devices AND many of the textures I am loading this way do work fine.
But I'm not sure what else could be causing it. A memory issue seems unlikely given that amount of memory available on the Xoom compared to the other devices the app works on.
Right now I don't own a zoom, but I can replicate the issue via DeviceAnywhere (where I see white backgrounds).
Nothing of interest shows up in LogCat either.
I know this isn't much to go on, but I'm at a loss here, what kinds of potential causes should I be looking at here? Thanks in advance for any ideas.
Try using glGetError() to see if OpenGL throws any errors
Is your application 2D or 3D? When you're drawing your sprites on the screen; which method are you using?
If your texture is white during onDrawFrame that probably depends on:
An untextured quad (using VBO:s or standard Vertex Arrays) - probably not, because it works on other devices
Xoom lacks support of the draw_texture extension - if you're using 2D
Xoom lacks support of VBO:s (Vertex Buffer Objects) - probably not, almost every Android device out there supports VBO:s
Do you have any sort of texture compression implemented that Xoom doesn't support?
At runtime, use this code to get the extensions and check if they're available:
String extensions = gl.glGetString(GL10.GL_EXTENSIONS);
boolean supportsDrawTexture = extensions.contains("GL_OES_draw_texture");
// Continue here and sooner or later you should see where Xoom lacks support
// where other devices doesn't.
Is it possible that you're falling foul of Android's automatically-resize-bitmaps behaviour? Print out the bitmap sizes as they are loaded to check, or move them to res/drawable-nodpi to avoid the behaviour entirely.
Is it possible that your texture exceeds 2048 pixels width or height? That's the maximum allowed texture size on XOOM.