Some facts about the Android graphics system

Now the internet is flying all kinds of information on the Android image rendering of hydrology is really annoying me, below to give you some information on the Android hardware rendering the truth, hardware acceleration is not what we think so perfect, and we have been improving!

1. Android has been using hardware acceleration. In fact, since the 1.0 version, all of the window elements are synthesized and displayed through hardware.

2. This means that many of the animations you see are accelerated: The display of buttons, the shadow of the notification bar, the toggle animation between different activity, pop-up windows, and the display and concealment of cue boxes, and so on.

3.Android used software methods (as opposed to hardware acceleration) to control the rendering of individual window elements, such as the UI for the following figure, which includes four window components: status bar, wallpaper, initiator on the desktop, and menu. If one of the elements changes its content, such as highlighting a menu item, for a previous version of 3.0, http://www.aliyun.com/zixun/aggregation/10478.html "> system uses software to draw new content, However, not all elements need to be redrawn, and the stitching of each window element is done by hardware. Similarly, the Movement of any window: for example, the top and bottom motions of a menu are completely rendered by hardware.

4. Now we focus on the interior rendering of the window elements, and in fact, you don't necessarily need hardware acceleration to achieve a FPS of 60 frames per second. The frame rate depends on the number of pixels to display and the speed of the CPU. For example, the second son can complete any ordinary native UI animation at 60FPS speed on its 800*480 resolution screen, such as the scrolling of the list, and no problem at all. The original Droid series was difficult to achieve at this rate.

5. The "full" hardware acceleration drawing of the window can be implemented in Android3.0. No more features were introduced in Android 4.0. Starting with 3.0, if you set a flag in your application to allow hardware to accelerate, then all the windows will be drawn to the GPU to complete. The main change in Android 4.0 is that hardware acceleration is turned on by default in Android4.0 or later applications, and no more need to set android:handwareaccelerated= "true" in the configuration file. (And we do not allow previous applications to turn on hardware acceleration by default, because hardware acceleration is not a good way to do some special drawing operations, and when the application needs a part of the UI update, it will affect some of its performance.) For many existing applications, forced to turn on hardware acceleration, will obviously interrupt the operation of the application

6. Hardware acceleration is not as perfect as everyone thinks. For example, on PVR-driven devices such as the second son and the third son, it takes 8M of RAM to open OpenGL in the process. The cost of comparing the general process to 2M is huge. RAM is limited, and a large portion is drawn, so other running processes are having problems with missing memory, such as reducing the speed of switching between applications.

7. Because of the extra cost of OpenGL, we'd better not use it too much for drawing. For example, some of the jobs we're doing now are designed to allow Android 4.0 to work smoothly with the second son without hardware acceleration: we don't have to waste 8MB of memory in the system process, and we don't need to waste an extra 8 m of memory on the phone process, or 8MB memory in the system UI process, etc. Believe me, you won't notice-it's no good to use OpenGL to draw something like a status bar or a gorgeous animation.

8. Hardware acceleration is not a "cure" for fluent UI. We tried a lot of different ways for the fluency of the UI, such as the scheduling strategy for the foreground/background process introduced in 1.6, the rewrite of the input system in 2.3, the use of "severe mode", the concurrent garbage collection mechanism, loader, and so on. If you want to reach the 60fps frame rate, you only have 20 milliseconds to process the contents of each frame. This time is not very long, the process of reading the memory card in the UI processes will result in a delay greater than this time limit, especially in the write operation.

9. For some recent examples of the impact of UI fluency: we notice that on the second son, scrolling through the list at 4.0 is not as smooth as using 2.3. The reason for this phenomenon is the slight drift of the timer: Sometimes the application is receiving the touch event and drawing on the screen, and when the last action is not finished, it receives the next event and begins to draw, causing it to lose the current frame. In spite of this phenomenon, the frame speed can reach a stable 60FPS. (Of course, this question has been amended)

10. When people compare the scrolling fluency of Android with iOS browsers, the difference they see is not the result of hardware acceleration being turned off. At first, Android used a completely different rendering strategy and made some compromises: the page was converted into a "display list" that continued to be drawn on the screen rather than in the form of blocks (Tiles). It has one advantage: the phenomenon that the blocks are not being rendered when scrolling or scaling is not happening (translator Note: Early iOS this phenomenon is very obvious, fast scrolling to the bottom of the page will wait for a piece of the drawing out). And this method is not to the point of the page is complex, the frame speed is significantly lower. For example, the browser is now starting to use blocks in the way of rendering, so it can be scrolling or zoom in to maintain a stable frame speed, naturally there will be a new block is not immediately rendered out of the situation. and each block is drawn in software, which I believe is true in iOS. (In versions prior to 3.0, hardware acceleration is not turned on, and block based policies can be used.) And as I mentioned earlier, the second son can easily reach 60FPS)

11. Hardware acceleration does not magically make the problem of drawing disappear. GPU performance is a very important limitation. An interesting recent example: the Tegra2 tablet based on Nvidia can easily access any pixel in the 2.5 1280*800 resolution screen at 60FPS speed. Now consider switching to all application lists in Android 3.0: you need to draw the background (1x all pixels), followed by shortcuts and desktop gadgets (assuming little content, cost 0.5x), followed by the black background for all applications (1x), and then the icon for all applications (0.5x )。 Obviously, we have exceeded our original budget, and at this point we haven't finished stitching the individual window elements and making the final display. To get 60FPS of animation, Android 3.0 and later versions use a series of tips. One of the main things is that it tiles all the window elements in one layer instead of copying them to the CPU cache. But even so, we're already out of the budget, but luckily we're using another trick: because the background in Android is a separate window element, we can set it to place the entire bitmap larger than the screen, and now the user starts sliding, the background is moving, and no special drawing is needed. Just move the window, and since the window is on a tiled layer, we don't even need to use the GPU to organize this window element into the screen.

12. With the increase of screen resolution, it is closely related to the speed of 60FPS and GPU, especially the bandwidth of memory bus. In fact, if you want to improve the effectiveness of your hardware, pay special attention to increasing the bandwidth of the memory bus. Many times the CPU (especially the CPU with the perfect neon instruction set) will be larger than the memory bus block.

UPDATE: There is so much discussion underneath, but I have the ability to explain all the relevant issues. But I will try to provide some ideas that I think are more interesting here.

Some people think that the rabbit has a very fluent UI and that they have gone beyond the third son and made a lot of improvements. In fact, we ignore a lot of equipment differences, the Furious rabbit screen is sized and the third son is 720*1280. If the second son can reach 60FPS on its sized screen, the Furious rabbit with the more NB CPU must have the same fluency.

The biggest difference between the two is that the three sons need to draw 2.4 times times as many pixels as the furious rabbit. This is equivalent to 2.4 times times the speed of a single nucleus. (It should be pointed out that multi-core is meaningless when the UI is rendered, because rendering must be done in one process and cannot be parallel)

This is why hardware acceleration is important: As the pixel increases, the GPU is usually better at processing image operations. In fact, this is our biggest driver for introducing hardware acceleration into Android. On the 720*1280 screen, the existing ARM CPU is hard to reach 60FPS, but the GPU rendering is different. Similarly, in comparison with the Furious rabbit, at the same time open no hardware acceleration applications, in the third son can not reach the same 60FPS rabbit, because it has to render 2.4 times times the rabbit's pixel.

In the end, there is another advantage to the GPU: many of the effects of rendering have become easier. For example, you want to draw a bitmap in software form, you can not do anything except set a displacement. It takes a considerable amount of time to render it just by shrinking. In the GPU, such conversions are fairly easy. This is the horse for God. New default theme Holo use hardware acceleration to draw backgrounds. In applications where hardware acceleration is not enabled, such backgrounds are automatically removed

Original address: https://plus.google.com/105051985738280261832/posts/2FXDCz8x93s
(Note: Many of the comments that follow suggest that I'm writing this just to make Android less of an excuse for iOS cards or inconsiderate users, and so on, and I need to be clear here: The reason I'm writing this article is just to correct all the misconceptions about Android that are being spread online.) I'm not trying to explain anything, I just want to give a reference to those kids who are focused on Android and have been on the wrong cognitive puzzle on the Internet.