I have an application which uses Android ViewPager (7 views, pretty complex with images and animations). This application runs fantastically on my Asus Eee Pad. It is just gorgeous.
I also have a Galaxy Tab 2 10.1 which almost can not run the app... despite it's brand new and theoretically more powerfull than my EEE Pad. I would like to mention both terminals run Android 4.0.3 and their screen size is identical (1280x800). Application runs in landscape mode.
The application does not use sql, or internet access, just animations on different views and the swipe effect of the ViewPager.
I checked I think everything, from heap, from lint, from basically all the available tools for profiling but nothing seems to improve my UI performance on the Galaxy Tab 2... I wonder if there isn't some difference in the hardware finally, where the ASUS will use GPU to render the UI and the Galaxy Tab 2 its CPU...
I was wondering finally, if any of you, noticed some similar issues on Galaxy Tab or other tablets when comparing your app behaviors on multiple targets...
Cheers!
Paul
--- added September 6th ---
Well, it seems that, despite the Galaxy tablet should use hardware acceleration, it does not. When I am forcing each xml layout with android:layerType="hardware" and
v.setLayerType(View.LAYER_TYPE_HARDWARE, null);
ObjectAnimator oaAlpha = ObjectAnimator.ofFloat(v, "alpha",0f, 1f);
it works finally better... even if it is not as smooth as on the Asus one
Finally, I discovered - and this is really odd - that the performance issue was created by the fact that the font size was too high !?!
It was a sad experience... but for some stupid reason the Galaxy Tab 2.0 was having major issues rendering texts written with big sized letters. And it is related to the Galaxy Tabs (so I imagine hardware) because I tried with So just redesign your app with smaller fonts and don't forget to complain to Samsung.
Related
I'm currently developing an application that was originally meant to be run solely on Nexus 7 and Android 4.2. However, there was a change of plans and now it is meant to run on the Galaxy Tab 2, Android 4.1.1 instead.
I am using a custom font that rendered great on the Nexus 7. However, when downgrading the version of Android and switching to the Galaxy Tab 2, the font kerning got completely messed up and looks terrible. Spacing is way off from what it should be.
Any tips to point me in the right direction for fixing this issue? I don't have the slightest idea how to fix this, except for switching to a different font, which is less than ideal.
Sounds like you may have run across the kerning problem described here: Android Custom View code stopped working correctly in Jelly Bean 4.2
It is possible to work around it.
At glowscript.org are various demo programs written in JavaScript or CoffeeScript that involve little code.
For example, the one-line program box() creates a 3D cube that can be rotated and zoomed, thanks to many defaults (which can be overridden), including basic lighting (two distant lights and some ambient lighting).
Problem:
These programs run fine in many browsers on Windows, Mac, and Linux, but in Firefox on the Samsung Galaxy S3 they are very dark. The appearance indicates that ambient light works (increasing it makes the scene bright) but the distant lights don't work (no difference with them on or off). I've tried running some WebGL demos found on the web and they look fine.
Can anyone think of where I should look for the problem? Why should the behavior be so different between desktop/laptop behavior and what happens on the Galaxy S3?
I fixed the problem on the Galaxy smartphone and added the following to the GlowScript help:
"Most tablets and smart phones do not yet support WebGL, though this is likely to change. On the Samsung Galaxy S3 smartphone, Firefox and Opera do run GlowScript programs, though animations are slow, transparency is buggy, and currently there is no way to zoom and rotate. There are reports that GlowScript also works on the Sony Experia smartphone."
The problem was that the Galaxy shader compiler does not handle for loops correctly. In the fragment shader there was a for loop over the various lights (up to 8 lights). Variables set in the for loop were often set to zero instead of to the specified value. The solution consisted of replacing the loop with a straight-line structure like this, where LP(i) and LC(i) are light positions and colors:
if (light_count == 0) return;
calc_color(LP(0), LC(0));
if (light_count == 1) return;
calc_color(LP(1), LC(1));
if (light_count == 2) return;
etc.
Yuck. Fortunately we only have to support a finite number of lights.
I have a game which does a whole lot of image-scaling (once every time you enter a level). The scaling is done with a simple call to Bitmap.createScaledBitmap(Bitmap). I realize that until the garbage collector comes, I effectively have two copies of these images, but I've tested it to death on several Android devices, and only recently got a Galaxy S3. You would have thought that if a game runs perfectly well on the Xoom2, the Galaxy Tab and the Galaxy S2, to say nothing of lower-end models like the Galaxy Y and Galaxy Ace, it would run even better on the Galaxy S3. Embarrassingly, it doesn't, and all-too-often I run out of memory. I think I've optimized my game about as far as I'm willing to (admittedly, some optimization was called for). I'd like to understand the problem. Does anyone know of any memory-management problems regarding the S3? Is the screen size-RAM ratio worse than on, say, the Galaxy Tab? Thanks in advance.
If you're are scalling imgs you should use .isSampleSize in the BitmapFactory.Options before makes the bpm.
So I recently created a game with several activities. On my HTC Thunderbolt, all parts of the game seem to be running very fast; however, on my Galaxy 10.1, two of my five activities are running extremely slow (i.e. screen fading is slow, enemies and cursor are moving slow as well). I don't know what is wrong. The other activities are running at or at least near the speed my thunderbolt was running at. Can someone please help me?
Try enabling hardware accelerated graphics, which is available on Android 3.0+.
Or, if you are serious about game performance, use OpenGL instead.
First to thank you all for your great help, I have finally published my game puzzle, both full and free version. Not sure how would I do it without Stackoverflow.
I also learned a lot by helping others.
The issue I am having is that when I start applications I have developed, on Samsung Galaxy Tab, animations are jerky at first 10 seconds or so, then they become smooth. This is not the case on HTC desire or Samsung Europe mobile.
It does not matter whether the animation is a frame by frame canvas drawing or built in android view animations.
I wonder if there is something I can do to prevent this slow down; is it something to do the way Galaxy Tab buffers when loading an application and optimising the resources? Or is this to do with the fact that it has a higher resolution screen… or both.
One way to deal with this could be to create some kind of animated intro in the same activity which would preload/optimise Galaxy Tab for the game.
EDIT after few months of development:
When testing an app on Galaxy Tab it starts slow and the animation is jerky, but if I restart the app and/or unplug the USB link, then it run fast as it should.
It's hard to say without seeing any of you're code. I couldn't say if it's a general problem with your code that only becomes apparent on slower devices, or if it is actually an issue with the Tab.
When testing my applications on the Galaxy Tab the general user interface is slower than on a Galaxy S (2.2), Nexus S or HTC Hero (2.1) but there are reasons for this:
Nexus S has a better GPU and Android version
Samsung have enabled some hardware-acceleration wizardry in their later Galaxy S builds
The resolution of the Galaxy Tab is higher
My main experience has been that the effect of the garbage collector (GC) is much more prominent on the Tab, therefore it could be something to do with your memory management -- are you creating objects in your onDraw method?