Database Info

Android graphics true facts

Saw this one on google+ and I think it's a nice read and very informative
How about some Android graphics true facts?
I get tired of seeing so much misinformation posted and repeated all over the place about how graphics rendering works on Android. Here is some truth:
• Android has always used some hardware accelerated drawing. Since before 1.0 all window compositing to the display has been done with hardware.
• This means that many of the animations you see have always been hardware accelerated: menus being shown, sliding the notification shade, transitions between activities, pop-ups and dialogs showing and hiding, etc.
• Android did historically use software to render the contents of each window. For example in a UI like http://www.simplemobilereview.com/wp-content/uploads/2010/12/2-home-menu.png there are four windows: the status bar, the wallpaper, the launcher on top of the wallpaper, and the menu. If one of the windows updates its contents, such as highlighting a menu item, then (prior to 3.0) software is used to draw the new contents of that window; however none of the other windows are redrawn at all, and the re-composition of the windows is done in hardware. Likewise, any movement of the windows such as the menu going up and down is all hardware rendering.
• Looking at drawing inside of a window, you don’t necessarily need to do this in hardware to achieve full 60fps rendering. This depends very much on the number of pixels in your display and the speed of your CPU. For example, Nexus S has no trouble doing 60fps rendering of all the normal stuff you see in the Android UI like scrolling lists on its 800x480 screen. The original Droid however struggled with a similar screen resolution.
• "Full" hardware accelerated drawing within a window was added in Android 3.0. The implementation in Android 4.0 is not any more full than in 3.0. Starting with 3.0, if you set the flag in your app saying that hardware accelerated drawing is allowed, then all drawing to the application’s windows will be done with the GPU. The main change in this regard in Android 4.0 is that now apps that are explicitly targeting 4.0 or higher will have acceleration enabled by default rather than having to put android:handwareAccelerated="true" in their manifest. (And the reason this isn’t just turned on for all existing applications is that some types of drawing operations can’t be supported well in hardware and it also impacts the behavior when an application asks to have a part of its UI updated. Forcing hardware accelerated drawing upon existing apps will break a significant number of them, from subtly to significantly.)
• Hardware accelerated drawing is not all full of win. For example on the PVR drivers of devices like the Nexus S and Galaxy Nexus, simply starting to use OpenGL in a process eats about 8MB of RAM. Given that our process overhead is about 2MB, this is pretty huge. That RAM takes away from other things, such as the number of background processes that can be kept running, potentially slowing down things like app switching.
• Because of the overhead of OpenGL, one may very well not want to use it for drawing. For example some of the work we are doing to make Android 4.0 run well on the Nexus S has involved turning off hardware accelerated drawing in parts of the UI so we don’t lose 8MB of RAM in the system process, another 8MB in the phone process, another 8MB in the system UI process, etc. Trust me, you won’t notice -- there is just no benefit on that device in using OpenGL to draw something like the status bar, even with fancy animations going on in there.
• Hardware accelerated drawing is not a magical silver bullet to butter-smooth UI. There are many different efforts that have been going on towards this, such as improved scheduling of foreground vs. background threads in 1.6, rewriting the input system in 2.3, strict mode, concurrent garbage collection, loaders, etc. If you want to achieve 60fps, you have 20 milliseconds to handle each frame. This is not a lot of time. Just touching the flash storage system in the thread that is running the UI can in some cases introduce a delay that puts you out of that timing window, especially if you are writing to storage.
• A recent example of the kinds of interesting things that impact UI smoothness: we noticed that ICS on Nexus S was actually less smooth when scrolling through lists than it was on Gingerbread. It turned out that the reason for this was due to subtle changes in timing, so that sometimes in ICS as the app was retrieving touch events and drawing the screen, it would go to get the next event slightly before it was ready, causing it to visibly miss a frame while tracking the finger even though it was drawing the screen at a solid 60fps.
• When people have historically compared web browser scrolling between Android and iOS, most of the differences they are seeing are not due to hardware accelerated drawing. Originally Android went a different route for its web page rendering and made different compromises: the web page is turned in to a display list, which is continually rendered to the screen, instead of using tiles. This has the benefit that scrolling and zooming never have artifacts of tiles that haven’t yet been drawn. Its downside is that as the graphics on the web page get more complicated to draw the frame rate goes down. As of Android 3.0, the browser now uses tiles, so it can maintain a consistent frame rate as you scroll or zoom, with the negative of having artifacts when newly needed tiles can’t be rendered quickly enough. The tiles themselves are rendered in software, which I believe is the case for iOS as well. (And this tile-based approach could be used prior to 3.0 without hardware accelerated drawing; as mentioned previously, the Nexus S CPU can easily draw the tiles to the window at 60fps.)
• Hardware accleration does not magically make drawing performance problems disappear. There is still a limit to how much the GPU can do. A recent interesting example of this is tablets built with Tegra 2 -- that GPU can touch every pixel of a 1280x800 screen about 2.5 times at 60fps. Now consider the Android 3.0 tablet home screen where you are switching to the all apps list: you need to draw the background (1x all pixels), then the layer of shortcuts and widgets (let’s be nice and say this is .5x all pixels), then the black background of all apps (1x all pixels), and the icons and labels of all apps (.5x all pixels). We’ve already blown our per-pixel budget, and we haven’t even composited the separate windows to the final display yet. To get 60fps animation, Android 3.0 and later use a number of tricks. A big one is that it tries to put all windows into overlays instead of having to copy them to the framebuffer with the GPU. In the case here even with that we are still over-budget, but we have another trick: because the wallpaper on Android is in a separate window, we can make this window larger than the screen to hold the entire bitmap. Now, as you scroll, the movement of the background doesn’t require any drawing, just moving its window... and because this window is in an overlay, it doesn’t even need to be composited to the screen with the GPU.
• As device screen resolution goes up, achieving a 60fps UI is closely related to GPU speed and especially the GPU’s memory bus bandwidth. In fact, if you want to get an idea of the performance of a piece of hardware, always pay close attention to the memory bus bandwidth. There are plenty of times where the CPU (especially with those wonderful NEON instructions) can go a lot faster than the memory bus.
All credit goes to Dianne Hackborn. Thanks for sharing this!

HAHAHAHA good facts, and very interesting!

Great post

yup, Nice Post!

Interesting observation!

[Discussion] Ways to improve UI response on Android

Given the recent hoopla in the blogosphere about how iOS places higher priority on User Interface actions than Android. I was wondering what ideas can be implemented in current Android or Linux kernels to get better UI response.
Overclocking or upgrading to a faster phone is the brute force way, a smarter way would be to give higher priority to user input instead of benchmark/multitasking score numbers. I think it makes sense to give the User input highest priority because in computation timeframes, user input is rare, and considering how important smoothness affects overall perception & enjoyment of a device, it's a good idea to allow other OS background tasks to take a backseat when the User wants to do something.
I'll start the discussion with two ideas I've implemented in a kernel recently that has shown improvements in UI response.
1. Switched to using SIO (Simple IO) scheduler (similar, but slightly lower benchmarks than Noop). Main difference is SIO prevents the system from hogging resources when large amounts of data needs to be read/written. It has a timeout so UI threads has a chance to run also.
2. Switched the touchscreen driver interrupt service request from using the general events workqueue (schedule_work()) to a dedicated workqueue (queue_work()). Touchscreen generated actions get to ride in the fast lane.
Any other ideas people have?

How bout some NSA IN THAT KERNEL
via Dan swagger

Usefull links, that clear things out:
https://plus.google.com/100838276097451809262/posts/VDkV9XaJRGS
https://plus.google.com/105051985738280261832/posts/XAZ4CeVP6DC
http://blog.crazybob.org/2011/12/truth-about-android-ios-ui-performance.html

the thing is i may be using a note but when using ICS with apps that are updated for ICS, i feel its smooth enough. the real difference is i think ios uses completely different method for scrolling i.e. the bounce function and slight delay in finger recognition. same with ios touch recognition, it just somehow is better no doubt.
btw when i was miui with bounce it definitely felt smoother but although it wasnt ios smooth.
Sent from my Galaxy Note using XDA App

The main difference between ios and android is the fact they use ram in two totally different ways. Ios handles ram in a manner to make the user interface smooth as possible all the time while android frees ram to make multitasking better. The problem that android has is changing the way android handles ram to make the interface smoother for the user. They wont be able to for a long time because they have to do a total overhaul on the whole dalvik cache type setup that android uses.
Sent from my Incredible 2 using Tapatalk

i recently started using supercharger v6 which messes around with the ram and how it should be allocated for desired operations. I don't know if it's relevant but do you think it makes a difference and which setting would get you a better scrolling experience?

I liked the supercharger when I used the Droid Eris but since I've upgraded I get more redraws than without it. I used the 768hp I think.
Sent from my Incredible 2 using Tapatalk

you could edit the ramdisk to set more of a priority to rosie.apk or whatever launcher you use...just a thought

That would be the same as locking home in memory.
Sent from my Incredible 2 using Tapatalk

shad0wboss said:
i recently started using supercharger v6 which messes around with the ram and how it should be allocated for desired operations. I don't know if it's relevant but do you think it makes a difference and which setting would get you a better scrolling experience?
Click to expand...
Click to collapse
There are a number of issues that contribute to a "sluggish experience". The supercharger v6 script mainly keeps more memory free so that switching to new apps cuts down on the garbage cleanup of older apps. One of the downsides I've noticed with more aggressive lowmemkiller settings is a lot of apps get killed in the background when they need to stay for when users want to multitask.
The hardware acceleration route has downsides too from what I've heard, it requires more RAM per app just to have it enabled.
One of the articles posted earlier has good insight. Mainly because a lot of apps share a general events queue, and developers should not have a lot of blocking code in there, but developers make mistakes. The tools available for Android to develop and tweak UI performance seems lacking at this point.

How about SIGSTOPping everything else when you touch?

Questions or Problems Should Not Be Posted in the Development Forum
Please Post in the Correct Forums
Moving to General

does it work with samsung i9000?

Supercharger?
Sent from my Sabotaged Droid Incredible 2.

I find that either turning off cpufreq (by using the Performance governor) or increasing the lower frequency makes things a bit more snappy. For most governors, there's a delay between CPU load and the frequency being increased. This delay is usually noticeable if the CPU load is due to me working with the interface. By increasing the min frequency to, say 800mhz on a Nexus S, this makes things a lot more snappy than the default setting of 200mhz.
Another thing that helps with the smoothness (at least for me, in ICS) is the setting that forces GPU acceleration for all apps. For example, apps these days (well twitter and Facebook) have that pull down to refresh widget from iOS. Without forcing GPU acceleration, the rotating arrow animation usually hitches quite a bit, but is smoothed out with this setting on. This setting can be found in the developer options in the settings.
Hope these help,
- chris

Turning up the min CPU can cause freezes on some peoples phone though and using the performance governor can drain the battery quick. The reason the CPU scales up the way it does before it gets to max frequency is to save battery.
Sent from my Sabotaged Droid Incredible 2.

System tuner pro has alot of tweaking options that on memory use
those that use launcher pro can find a memory usage setting in launcher pro to.

disconnecktie said:
Turning up the min CPU can cause freezes on some peoples phone though and using the performance governor can drain the battery quick. The reason the CPU scales up the way it does before it gets to max frequency is to save battery.
Sent from my Sabotaged Droid Incredible 2.
Click to expand...
Click to collapse
Agreed, but the whole point here was to help improve UI responsiveness. Without rearchitecting the OS, a good way is to allow the CPU (which is busy sharing its resources with non-UI work) to react more quickly is to ensure the CPU is at a higher clock rate before the UI needs it.
As for battery life, it really depends on your usage pattern. If you have a lot of background processing going on, preventing the CPU from going to sleep when idle, you may be better off scaling back the minimum cpufreq frequently. If your CPU actually goes to sleep, give scaling things up a try. A handy tool you can use to see how often the CPU is sleeping is CPU Spy. To see which apps are keeping the CPU awake, there's a program called Better Battery Stats available on XDA and market.
As for stability, I don't mean over clocking the CPU...all I'm suggesting is to increase the frequency the CPU goes to when the screen is on, but nothing much is happening. This should still keep things within safe limits.
Hope this helps,
- chris

I find the interactive governor does a very good job of ramping to max right from idle (instead of waiting even a few ms like ondemand does). It assumes coming out of idle the CPU is starved. Then scales back once demand lowers. No fancy locking to min freq when screen is off (which can stutter some background apps).

There is many thing what can be done in the code of the applications. For example once I had a really sluggish app. It turned out that while I was dragging an item in the UI, the UI needed to be relayouted, and the draw calls were simply postponed: in android (at least that was the case before ICS) the drawing of the UI is delayed while the UI thread is too busy with events and layout requests.
To find these issues it's really useful to use traceview.

[APP][2.3+]Particles Fountain 3D

Hi !
I just published on the play store my first android app :
play.google.com/store/apps/details?id=com.valxp.particles
(it's my first post so I can't post links :crying
It's a 3D particle engine that uses all the power of your phone.
It runs a thread per CPU core and is developed in C++ using the android NDK.
It's not a really usefull app for now. It just moves depending on the music your phone is currently playing, so you can use it as a audio vizualiser.
At the beginning you can select the amount of particles, on my galaxy SII I can run smoothly 80,000 particles and 150,000 on my nexus 7.
I recommend you to keep the particle size under 2. After that it becomes ugly
Motion blur adds some speed effect, but it may be heavy for low-end phones so you can disable it if needed.
It's really battery consuming, but I limit the framerate of the engine at 60 FPS and android limit the GPU at 60 FPS too. So if you use a lower amount of particles, the battery consumption will be lower.
Tell me if you like it or not. If you have ideas, advices, insults... :cyclops:
It's my first post on XDA despite the fact that I have been here for a few years, I never felt like I could be usefull, so I hope I can now
English is not my native language, so don't hesitate to tell me if I did some grammar fails.
Enjoy ! (And comment )
EDIT : Added screenshot as attachment

screenshot

play.google.com/store/apps/details?id=com.valxp.particles
Replying to make a link.

[APP][3.0+][FREE] Super Touch 6.0.1

Here we present you the SUPER TOUCH -an android app to make your Android phone SUPER SMOOTH on Sliding, Zooming, List-scrolling.
FAQ: Please consider reading all the setup information when you open the app for the first time after installation
NOTE: This app is created and developed by Super Touch Developer I'm just creating op for him so any of its development work are not concerned with me...You can also mail your queries to [email protected]
App features:
1. Magnificent screen sliding respond, easy sliding on screen and no longer delay.
2. Incredibly smooth on zooming web pages or images as well as any operations needing to zoom.
3. Sliding to all directions is unbelievably quick and smooth.
4. Unbelievably quick and smooth lists rolling.
5. Much faster launching and loading Apps.
6. Speedy and accurate typing experience.
7. Much rapid on playing all sorts of games.
8. The first power-saving optimization app that does not affecting phones’ performance.
Super Touch allows you to experience unprecedented smooth smart phones.
Main functions：
One of this App’s main functions is to allow Android devices sliding much quicker and smoother, which will solve the problem of slow drag.
Sliding, dragging and zooming are far smoother; content follows up your fingertip; switching columns is also a lot quicker.
Lists rolling is extraordinarily speedier and smoother, typing is incredibly easier.
There is also a very practical power-saving optimization function, which doesn’t sacrifice the performance of the phone.
Screenshots:
Download:
Google play
Version Information:
Current Version: 6.0.1
compitable: android 3.0+ and supports both stock and custom ROMs
Thanks to Phone Arena for their app review
Thanks to Emily Wood for youtube video (watch it for test video)

I'm just asking some questions
How is using an app going to help with scrolling speed when it's after the device has been booted? Wouldn't that have to be started during bootup for it to be implemented at run time?
What files/libraries are being altered?

HasH_BrowN said:
I'm just asking some questions
How is using an app going to help with scrolling speed when it's after the device has been booted? Wouldn't that have to be started during bootup for it to be implemented at run time?
What files/libraries are being altered?
Click to expand...
Click to collapse
Every time the boot needs to be automatically optimized once and no modification of the system file..only docking system and touchscreen chip
thank you

After optimization, sliding is very smooth.

Seems to be many "helping" this dev by posting his app on XDA. But there is no need for multiple threads on the same app.
This one was first, http://forum.xda-developers.com/and...p-reduce-lag-make-touch-t3249927/post63847108
Thread closed, thanks!
Darth
Forum Moderator

Game Booster. wow

Firstly I don't game at all.
Long story short flicked all my chosen apps in game booster (custom option) to HIGHER PERFORMANCE.
Wtf did I not do this before!
I'm clearly very late to the Party
Up until now I had only customised my chosen apps to 1440/120hz, thinking that would be suffice to experience the 120Hz panel in all its glory - but I was wrong!
Now having flicked all options to top notch (CPU now 2.36ghz) the device is incredibly that much more responsive and faster.... I mean visibly a difference.
An initial quirk with scrolling & pinchZoom particularly in Chrome has now been mostly resolved with this Higher Performance selected.
The above won't come as a surprise to most of you I suspect, however this was worthy of expressing nonetheless - as these settings can easily have been overlooked.
I'm coming from a 5 year stint with Sony, where such CPU configurations out of the box were not present on Sony - so this Razer Game Booster feature is very very nice to have indeed.
As you'd have probably gathered yourselves I'm sure... The highest CPU frequency is the GLUE that really brings that 1440/120Hz magic to real light :good:
I'm now far more content with the feel & feedback of the screen & device - given that this (120Hz) is what sets the device apart from the rest.

i just set my phones resolution and screen refresh rate to max ive not even looked at the boost feature. Ive just gone and flicked the 3 way toggle in the Game Booster app from Custom Mode (default no customisation) to Performance Mode- says i loose 1h battery life which isnt a huge deal with our 4000mah battery as its already a decent battery that one hour i dont care about.
Lets see how this beast of a phone runs now!