My app, which has a list view with some scrolling, is performing very well (scrolling at 60fps) on all phones I have tested it with, Nexus One, Nexus 4 and Galaxy S3/4. But the performance is terrible on the Nexus 10, probably around 15fps or so.
I have analysed it to be the Execute part of the graphics pipeline. I have attached a screenshot of a Nexus 10 and a Nexus 4, which are running Android 4.3 and no funny stuff.
The UI is even drawn at the same size, with approx the same amount of pixels. So it is just covering some 20% of the surface on the Nexus 10 and 90% of the surface on the phones. This means that it's not the number of pixels that's the problem. Also, I have checked so that when I scroll, it is only the scrolling area that are updated, not the entire screen.
What I am wondering is, how do I find out what is causing the show Execute phase on the Nexus 10?
Cheers,
Mikael
I had troubles with scrolling when a lot of NumberPickers where on the screen. So slow!!
"Mihael Grev" advice mainView.setLayerType(View.LAYER_TYPE_HARDWARE, null);
Related
I'm developing an app. This app has an layout. The layout is fairly simple. To make it even simpler, let's say that the layout consists of TextView and CustomView. The purpose of this custom view is drawing a large bitmap (1080 x 700).
In CustomView I store an integer for image resource. In its constructor I'm executing an AsyncTask to start decompressing resource. When decompressing finishes the CustomView is invalidated. In draw method I'm checking if bitmap hasn't already been decompressed then it does nothing, if bitmap is decompressed then the CustomView is drawing it and freeing it resources.
So far so good :)
I have test devices:
1. ZTE blade III - 1GHz single core, 512MB RAM, running android 4.0.4 (API 15)
2. HTC Desire X - 1GHz single core, 1GB RAM, running android 4.1.1 (API 16)
3. HTC Sensation 1.5 GHz dual core, 768MB RAM, running android 4.4.4 (API 19, rooted)
4. Google Nexus 5, 2.27GHZ quad-core, 2GB RAM, running android 5.0.1 (API 21)
At the time of developing I was testing on device 1, because it should be the slowest and if there everything is OK, so it would be OK everywhere else. And yes the approach from above worked well on this device.
Then I tried to device 2 - everything was as expected.
Then device 3 - again everything is good. On this device I run "Profile GPU rendering" to see how good it really is. Most of the time the bars are below green line, just when the bitmap is showing on the screen, they are higher and dropping fps from 60+ to around 30, which is good again. First of all I thought that canvas.drawBitmap() is slow, but when I check it the results was - less than 1ms for executing canvas.drawBitmap(). I checked again bars from "Profile GPU rendering". The blue and orange onces were low and yellow was above green line. Then I checked what does these colors mean http://developer.android.com/about/versions/jelly-bean.html. The yellow one is for "waiting commands to complete" - so everything looks good.
On 4th device I was expecting the best performance, but....no. Here the entire UI thread is freezing when the bitmap have to be shown on screen. I run again "Profile GPU rendering". Here for my great surprise are 4 colors. The 3 from above and purple one. At the time when bitmap is shown on the screen and UI thread freezes exactly the purple bar is from bottom to top of the screen so I see only tiny blue and HUGE purple bar. I try to see what is that bar for and found that is mean "prepare" - https://android.stackexchange.com/questions/89017/what-does-purple-colour-mean-in-gpu-rendering-profiling.
So finally my question is what am I missing for drawing bitmaps for lollipop and why this prepare stage takes so long when drawing bitmaps? Is It connected to lollipop or to Nexus 5? It is impossible for Google to add new stage which slows down the UI pipeline
UPDATE:
So after a lot of testing I realized that I have missed something :)
Really stupid that I didn't realized it earlier, but.... :(
As I said the app is still under developing and because of that I am making just a single drawable and putting it inside drawable-nodpi folder. But in this case I put it in wrong folder, instead of drawable-nodpi, I put it in drawable. This was causing Nexus 5 to decode it 9 times large bitmap and this was causing slowness.
Very slow interactive drag performance (about 2 fps) while running a simple KineticJS version 5.0.2 app on Android Chrome (Android 4.3 on a Samsung Galaxy Note 10.1 2014 edition) BUT as soon as I select Chrome's setting to "Request desktop site" suddenly there's a massive performance increase of about 10x with the drag refresh rate. I'm not sure if this is a KineticJS issue or perhaps something else entirely. Running on a desktop browser on my workstation, performance is butter smooth.
Here's a description of the app: There's a bitmap in the background layer (900x600) and a PNG bitmap with alpha channel in the foreground layer (320x156) with draggable = true.
If I remove the background layer, then drag performance is OK.
Is there a way to solve this?
I have now achieved a consistent frame rate of roughly 30 to 40 fps on both mobile and desktop modes on the Samsung tablet mentioned above!
The big change came from restructuring my game code which erroneously called init() several times (about 6 times) instead of just once, each time instantiating the stage and the multiple images. I do also use "Kinetic.pixelRatio = 1" at the top of the code and a "Kinetic.FastLayer()" for my static background artwork.
I wanted to test android for a html5/Javascript web app, so I purchased a Nexus 7 (2nd gen), and upgraded the OS to the lastest 4.3.
The Nexus has substantially better specifications than my old test iPad 2:
2GB ram vs 512MB
1.5GHz x 4cores vs 1GHz x 2cores
However I'm finding the Nexus UI interaction on web pages is between ~5-10 times slower than the iPad. Button presses, animations and the like are very laggy. For example a button press flipping from pressed to unpressed on the iPad 2 keeps pace with as fast as your finger can twitch, even when drumming two fingers, (greater than 5/sec). Whereas the Nexus is noticeably lagging behind the user touch at less than 1/sec. In fact Android/Nexus is so slow it sometimes misses the un-touch event, leaving the button in the depressed state.
I am trying to get the the bottom of this, is it a limitation in the OS? A problem with the hardware? (this is googles own device though) Is the Java JVM overhead limiting performance? (though I'd think that Chrome is all native C/C++). Is there a fix?
I ran an Browser javascript test (Dromaeo), and the computational results are what you'd expect (the newer fast Nexus was around 2x the speed of the old iPad). Though I did notice that oddly the iPad out-performed the nexus in DOM manipulation tests by around 2x, though still not as dramatic as in the user experience.
Any thoughts?
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.
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?