Download as KEY, PPTX
Uploaded byRomain Guy
Google I/O 2011, Android Accelerated Rendering
The document discusses Android accelerated rendering. It describes how hardware acceleration allows Android to render UI elements on the GPU rather than the CPU. This improves performance by taking advantage of the GPU's parallel processing abilities. It outlines the new drawing model which uses display lists to cache drawing commands and reduce redundant work. Finally, it compares the old software rendering approach to the new hardware accelerated approach using display lists.
More Related Content
![[1D6]RE-view of Android L developer PRE-view](https://cdn.slidesharecdn.com/ss_thumbnails/1d6re-viewofandroidldeveloperpre-view-140929015428-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
![Governance, Deployment & Methodologies for Agentic Automation [2/3]](https://cdn.slidesharecdn.com/ss_thumbnails/agenticcommunityseries-day2-251112135038-a386476d-thumbnail.jpg?width=640&height=640&fit=bounds)
Google I/O 2011, Android Accelerated Rendering
- 2. Android Rendering Romain Guy @romainguy Chet Haase @chethaase May 11, 2011 Feedback goo.gl/wI57L Hashtags #io2011, #Android
- 3. Android Accelerated Rendering Romain Guy @romainguy Chet Haase @chethaase May 11, 2011 Feedback goo.gl/wI57L Hashtags #io2011, #Android
- 4.
- 6.
- 8. memcpy (MiB/s) Pixel count 1100 825 550 275 0 G1 Droid N1 NS XOOM
- 9. UI on theGPU
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20. attribute vec4 position; attributevec2 texCoords; uniform mat4 transform; uniform mat4 screenSpace; varying vec2 outTexCoords; varying vec2 linear; void main(void) { outTexCoords = texCoords; linear = vec2((screenSpace * position).x, 0.5); gl_Position = transform * position; } Text+gradient vertex shader
- 21. precision mediump float; varying vec2 outTexCoords; varying vec2 linear; uniform sampler2D sampler; uniform sampler2D gradientSampler; void main(void) { lowp vec4 color; vec4 gradient = texture2D(gradientSampler, linear); color = gradient * texture2D(sampler, outTexCoords).a; gl_FragColor = color; } Text+gradient fragment shader
- 22.
- 23.
- 24.
- 25. 1 <application android:hardwareAccelerated="true"> 2 <activity ... /> 3 <activity android:hardwareAccelerated="false" /> 4 </application>
- 26. getWindow().setFlags( WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED, WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED);
- 27.
- 28.
- 29.
- 30. Canvas clipPath clipRegion drawPicture drawPoints drawPosText drawTextOnPath drawVertices Paint setLinearText setMaskFilter setRasterizer Unsupported operations
- 31. 3D transforms, XOR,Diff, Canvas clipRect ReverseDiff ignored drawBitmapMesh Colors array ignored drawLines No anti-aliasing setDrawFilter Ignored Paint setDither Ignored setFilterBitmap Filtering always on setShadowLayer Works with text only Limitations
- 32. ComposeShader Cannot contain another ComposeShader Cannot contain two shaders of the same type Limitations
- 33.
- 34.
- 35. ViewRoot ViewGroup View View Old model
- 36. ViewRoot ViewGroup View View invalidate() Old model
- 37. ViewRoot ViewGroup View View invalidate() Old model
- 38. ViewRoot ViewGroup invalidate() View View invalidate() Old model
- 39. ViewRoot ViewGroup invalidate() View View invalidate() Old model
- 40. ViewRoot invalidate() ViewGroup invalidate() View View invalidate() Old model
- 41. ViewRoot invalidate() ViewGroup invalidate() View View invalidate() Old model
- 42. ViewRoot ViewGroup View View Old model
- 43. ViewRoot draw() ViewGroup View View Old model
- 44. ViewRoot draw() ViewGroup View View Old model
- 45. ViewRoot draw() ViewGroup draw() View View Old model
- 46. ViewRoot draw() ViewGroup draw() View View Old model
- 47. • No logic! •List of drawing commands • Cached when a View changes DisplayList
- 48. Save 3 DrawPatch Save 3 ClipRect20.00, 4.00, 99.00, 44.00, 1 Translate 20.00, 12.00 DrawText 9, 18, 9, 0.00, 19.00, 0x17e898 Restore RestoreToCount 0 DisplayList to draw a Button
- 49. ViewRoot ViewGroup DisplayList View A View B DisplayList B DisplayList A New model
- 50. ViewRoot ViewGroup DisplayList View A View B DisplayList B DisplayList A invalidate() New model
- 51. ViewRoot ViewGroup DisplayList View A View B DisplayList B DisplayList A mark dirty invalidate() New model
- 52. ViewRoot ViewGroup DisplayList View A View B DisplayList B DisplayList A mark dirty invalidate() New model
- 53. ViewRoot ViewGroup DisplayList invalidate() View A View B DisplayList B DisplayList A mark dirty invalidate() New model
- 54. ViewRoot invalidate() ViewGroup DisplayList invalidate() View A View B DisplayList B DisplayList A mark dirty invalidate() New model
- 55. rebuild ViewRoot ViewGroup DisplayList View A View B DisplayList B DisplayList A New model
- 56. rebuild ViewRoot ViewGroup rebuild DisplayList View A View B DisplayList B DisplayList A New model
- 57. ViewRoot ViewGroup DisplayList View A View B DisplayList B DisplayList A New model
- 58. draw() ViewRoot ViewGroup DisplayList View A View B DisplayList B DisplayList A New model
- 63. 1 background.draw(); 2 panel.draw(); 3 selector.draw(); 4 wifi.draw(); 5 turnOnWifi.draw(); 6 checkBox.draw(); Old model
- 64. 1 selector.draw(); 2 drawDisplayLists(); New model
- 65. Old model New model View.invalidate() Intersects a dirty View When does View.draw() run?
- 66. ViewRoot ViewGroup View View Old model
- 67. ViewRoot ViewGroup invalidate() View View Old model
- 68. ViewRoot ViewGroup invalidate() View View Old model
- 69. ViewRoot invalidate() ViewGroup invalidate() View View Old model
- 70. ViewRoot invalidate() ViewGroup invalidate() View View Old model
- 71. ViewRoot ViewGroup View View Old model
- 72. ViewRoot draw() ViewGroup View View Old model
- 73. ViewRoot draw() ViewGroup View View Old model
- 74. ViewRoot draw() ViewGroup draw() View View Old model
- 75. ViewRoot draw() ViewGroup draw() draw() View View Old model
- 76. ViewRoot ViewGroup DisplayList View A View B DisplayList B DisplayList A New model
- 77. ViewRoot invalidate() ViewGroup DisplayList View A View B DisplayList B DisplayList A New model
- 78. ViewRoot invalidate() ViewGroup DisplayList mark dirty View A View B DisplayList B DisplayList A New model
- 79. ViewRoot invalidate() ViewGroup DisplayList mark dirty View A View B DisplayList B DisplayList A New model
- 80. ViewRoot invalidate() invalidate() ViewGroup DisplayList View A View B DisplayList B DisplayList A New model
- 81. ViewRoot draw() invalidate() ViewGroup DisplayList View A View B DisplayList B DisplayList A New model
- 82. ViewRoot invalidate() ViewGroup DisplayList rebuild View A View B DisplayList B DisplayList A New model
- 83. ViewRoot invalidate() ViewGroup DisplayList rebuild View A View B DisplayList B DisplayList A New model
- 84.
- 85. Button draw() DisplayList Display Save DrawPatch ClipRect Translate DrawText Restore
- 86. Button draw() draw() DisplayList Layer Display Save DrawPatch ClipRect Translate DrawText Restore
- 87. view.setLayerType(View.LAYER_TYPE_NONE, null) 3 types of layers
- 88. view.setLayerType(View.LAYER_TYPE_SOFTWARE, null) Software layer
- 89. view.setLayerType(View.LAYER_TYPE_HARDWARE, null) Hardware layer
- 90. 1. Performance Hardwarelayers
- 91. Drawing a ListView Hardware layer DisplayList Software Time in ms 0.009 2.1 10.3 Measured when drawing a ListView with Android 3.0 on a Motorola XOOM
- 92. 2. Visual effects Hardwareand software layers
- 94. ColorMatrix m =new ColorMatrix(); m.setSaturation(0.0f); Paint p = new Paint(); p.setColorFilter(new ColorMatrixColorFilter(m)); page.setLayerType(LAYER_TYPE_HARDWARE, p);
- 95.
- 96. 4. Animations Hardware andsoftware layers
- 97. Opacity Position Size Orientation Origin alpha x scaleX rotation pivotX y scaleY rotationX pivotY translationX rotationY translationY Layers-friendly properties
- 98. ViewRoot ViewGroup DisplayList View A View B Layer B DisplayList A Layers-friendly properties
- 99. ViewRoot ViewGroup DisplayList View A View B Layer B DisplayList A setRotationY(45) Layers-friendly properties
- 100. ViewRoot ViewGroup DisplayList invalidate() View A View B Layer B DisplayList A setRotationY(45) Layers-friendly properties
- 101. ViewRoot mark dirty ViewGroup DisplayList invalidate() View A View B Layer B DisplayList A setRotationY(45) Layers-friendly properties
- 102. ViewRoot mark dirty ViewGroup DisplayList invalidate() View A View B Layer B DisplayList A setRotationY(45) Layers-friendly properties
- 103. Save 3 DrawDisplayList A DrawLayerB Restore Parent DisplayList
- 104. viewB.setRotationY(45) Save 3 DrawDisplayList A DrawLayerB Restore Parent DisplayList
- 105. viewB.setRotationY(45) Save 3 Save 3 DrawDisplayList A DrawDisplayList A DrawLayer B Rotate 0.0, 45.0, 0.0 Restore DrawLayer B Restore Parent DisplayList
- 106. view.setLayerType(View.LAYER_TYPE_HARDWARE, null); ObjectAnimator.ofFloat(view, "rotationY",180).start(); Animating a complex View efficiently
- 107. view.setLayerType(View.LAYER_TYPE_HARDWARE, null); ObjectAnimator animator= ObjectAnimator.ofFloat( view, "rotationY", 180); animator.addListener(new AnimatorListenerAdapter() { @Override public void onAnimationEnd(Animator animation) { view.setLayerType(View.LAYER_TYPE_NONE, null); } }); animator.start();
- 108.
- 109. 1. Don’t usetoo many views Keep your hierarchy flat
- 110. 2. Be carefulof setAlpha() Without hardware layers, it costs 2x the fill-rate
- 111. 3. Reuse renderingobjects Don’t create new Paints, Bitmaps, etc. in draw()
- 112. 4. Don’t modifyBitmaps often Every change causes a texture upload
- 113. 5. Don’t modifyPaths often Every change causes a new rasterization
- 114. 6. Avoid overdraw GPUsare fill-rate limited
- 115. 7. Profile DDMS andtraceview are your friends
- 116. Android blog d.android.com Romain’sblog curious-creature.org Chet’s blog graphics-geek.blogspot.com
- 117.
- 118. Q&A Feedback http://goo.gl/wI57L Hashtags #io2011, #Android
Editor's Notes
- #2 \n
- #3 \n
- #4 \n
- #5 Since Android 1.0: hardware OpenGL ES 1.x and 2.x support\nWindows composition\nGames\nRich media (live wallpapers)\n
- #6 But the UI remains in software\n
- #7 Aren&#x2019;t we done?\nFaster CPUs, multi-cores, etc.\n
- #8 New, richer experiences\nMore smoother animations\nMore and more pixels (tablets, hdpi screens)\n
- #9 Software cannot keep up\nGraph from 2008 to 2011\nYellow bar increase at the same rate or faster rate\n
- #10 Android 3.0 has many new features\nFavorite new UI toolkit feature: GPU support\nAll 2D ops run with OpenGL on the GPU\nAll standard apps run on the GPU\n
- #11 Android 3.0 has many new features\nFavorite new UI toolkit feature: GPU support\nAll 2D ops run with OpenGL on the GPU\nAll standard apps run on the GPU\n
- #12 Android 3.0 has many new features\nFavorite new UI toolkit feature: GPU support\nAll 2D ops run with OpenGL on the GPU\nAll standard apps run on the GPU\n
- #13 Android 3.0 has many new features\nFavorite new UI toolkit feature: GPU support\nAll 2D ops run with OpenGL on the GPU\nAll standard apps run on the GPU\n
- #14 Android 3.0 has many new features\nFavorite new UI toolkit feature: GPU support\nAll 2D ops run with OpenGL on the GPU\nAll standard apps run on the GPU\n
- #15 How does it work?\nHere&#x2019;s the software rendering pipeline (pre-3.0 or apps without h/w in 3.0+)\n
- #16 The new hw accelerated pipeline translates Canvas calls to OpenGL\nOpenGL primitives are rasterized by the GPU\n
- #17 We have points, lines, triangles and textures\nEach draw call is a combo of those\nHere is a ListView, you can notice the fades at top/bottom\n
- #18 A simple button, 9patches are great in OpenGL\nResult is a simple mesh + texture\n
- #19 A path is rendered using a combination of geometry (quad) and an alpha texture\nColor is applied in the fragment shader\nText is drawn in a similar way\n
- #20 A path is rendered using a combination of geometry (quad) and an alpha texture\nColor is applied in the fragment shader\nText is drawn in a similar way\n
- #21 A path is rendered using a combination of geometry (quad) and an alpha texture\nColor is applied in the fragment shader\nText is drawn in a similar way\n
- #22 A path is rendered using a combination of geometry (quad) and an alpha texture\nColor is applied in the fragment shader\nText is drawn in a similar way\n
- #23 A path is rendered using a combination of geometry (quad) and an alpha texture\nColor is applied in the fragment shader\nText is drawn in a similar way\n
- #24 A path is rendered using a combination of geometry (quad) and an alpha texture\nColor is applied in the fragment shader\nText is drawn in a similar way\n
- #25 A path is rendered using a combination of geometry (quad) and an alpha texture\nColor is applied in the fragment shader\nText is drawn in a similar way\n
- #26 Here&#x2019;s an example of the vertex shader used to draw text filled with a gradient\nShaders are generated at runtime by the pipeline\nSeveral millions of shaders can be thus generated\n
- #27 Drawing text with a gradient requires 2 textures:\n- an alpha texture for text\n- the gradient texture\n
- #28 To enable 2D h/w acceleration, put this in AndroidManifest.xml\nThat&#x2019;s all you need to do\n
- #29 To enable 2D h/w acceleration, put this in AndroidManifest.xml\nThat&#x2019;s all you need to do\n
- #30 Hardware acceleration can be enabled/disabled at several levels\nLet&#x2019;s see how it can be done at each level\n
- #31 Here, enabled for the app, disabled for an activity\n
- #32 It can also be enabled for a specific window\n(for instance in Activity.onCreate())\n
- #33 H/w acceleration can be disabled per View\nWe&#x2019;ll talk more about layers later\n
- #34 If you write custom views, checking the hw accel. status might be important\nCanvas.isHardwareAccelerated() is the preferred method\nView.isHA() && !Canvas.isHA() is possible (e.g. bitmap cache)\n
- #35 Because of the nature of the 2D API and what GL can do, not everything will work\nSome features are missing, some are limited\nAll standard views/drawables will work\n
- #36 Some ops will be supported in future releases (drawPoints for instance)\nIf these ops are needed, draw in a Bitmap, or use a software layer\n
- #37 Some limitations will be lifted in future releases (AA lines for instance)\n
- #38 ComposeShaders are very useful\nCurrent constraints\n
- #39 An easy workaround is to use a software layer\nYou can also use a Bitmap, or Canvas.isHardwareAccelerated()\n
- #40 The new rendering pipeline changes the way rendering works\nIt&#x2019;s still an immediate mode\nBut with a special kind of caching\n
- #41 In the old model, invalidate()ing a View meant redrawing each parent\nThis executes a lot of Java code\nBut the logic remains the same for the parents!\nExpensive!\n
- #42 In the old model, invalidate()ing a View meant redrawing each parent\nThis executes a lot of Java code\nBut the logic remains the same for the parents!\nExpensive!\n
- #43 In the old model, invalidate()ing a View meant redrawing each parent\nThis executes a lot of Java code\nBut the logic remains the same for the parents!\nExpensive!\n
- #44 In the old model, invalidate()ing a View meant redrawing each parent\nThis executes a lot of Java code\nBut the logic remains the same for the parents!\nExpensive!\n
- #45 In the old model, invalidate()ing a View meant redrawing each parent\nThis executes a lot of Java code\nBut the logic remains the same for the parents!\nExpensive!\n
- #46 In the old model, invalidate()ing a View meant redrawing each parent\nThis executes a lot of Java code\nBut the logic remains the same for the parents!\nExpensive!\n
- #47 In the old model, invalidate()ing a View meant redrawing each parent\nThis executes a lot of Java code\nBut the logic remains the same for the parents!\nExpensive!\n
- #48 In the old model, invalidate()ing a View meant redrawing each parent\nThis executes a lot of Java code\nBut the logic remains the same for the parents!\nExpensive!\n
- #49 In the old model, invalidate()ing a View meant redrawing each parent\nThis executes a lot of Java code\nBut the logic remains the same for the parents!\nExpensive!\n
- #50 In the old model, invalidate()ing a View meant redrawing each parent\nThis executes a lot of Java code\nBut the logic remains the same for the parents!\nExpensive!\n
- #51 In the old model, invalidate()ing a View meant redrawing each parent\nThis executes a lot of Java code\nBut the logic remains the same for the parents!\nExpensive!\n
- #52 In the old model, invalidate()ing a View meant redrawing each parent\nThis executes a lot of Java code\nBut the logic remains the same for the parents!\nExpensive!\n
- #53 In the old model, invalidate()ing a View meant redrawing each parent\nThis executes a lot of Java code\nBut the logic remains the same for the parents!\nExpensive!\n
- #54 In the old model, invalidate()ing a View meant redrawing each parent\nThis executes a lot of Java code\nBut the logic remains the same for the parents!\nExpensive!\n
- #55 In the old model, invalidate()ing a View meant redrawing each parent\nThis executes a lot of Java code\nBut the logic remains the same for the parents!\nExpensive!\n
- #56 In the old model, invalidate()ing a View meant redrawing each parent\nThis executes a lot of Java code\nBut the logic remains the same for the parents!\nExpensive!\n
- #57 In the old model, invalidate()ing a View meant redrawing each parent\nThis executes a lot of Java code\nBut the logic remains the same for the parents!\nExpensive!\n
- #58 In the old model, invalidate()ing a View meant redrawing each parent\nThis executes a lot of Java code\nBut the logic remains the same for the parents!\nExpensive!\n
- #59 In the old model, invalidate()ing a View meant redrawing each parent\nThis executes a lot of Java code\nBut the logic remains the same for the parents!\nExpensive!\n
- #60 In the old model, invalidate()ing a View meant redrawing each parent\nThis executes a lot of Java code\nBut the logic remains the same for the parents!\nExpensive!\n
- #61 DisplayList are simplified lists of drawing commands\nOne DisplayList per View, cached when a View changes\nTo redraw a View, we just re-issue its DisplayList\n
- #62 Here is an example of a DisplayList: this draws a button\nSeveral 100s of lines of Java code are required to produce this\n
- #63 A DisplayList can reference other DisplayLists\nNote that only one DisplayList is rebuilt, nothing else is touched!\nMuch less code is executed\nDrawing a display list = native code only\n\n
- #64 A DisplayList can reference other DisplayLists\nNote that only one DisplayList is rebuilt, nothing else is touched!\nMuch less code is executed\nDrawing a display list = native code only\n\n
- #65 A DisplayList can reference other DisplayLists\nNote that only one DisplayList is rebuilt, nothing else is touched!\nMuch less code is executed\nDrawing a display list = native code only\n\n
- #66 A DisplayList can reference other DisplayLists\nNote that only one DisplayList is rebuilt, nothing else is touched!\nMuch less code is executed\nDrawing a display list = native code only\n\n
- #67 A DisplayList can reference other DisplayLists\nNote that only one DisplayList is rebuilt, nothing else is touched!\nMuch less code is executed\nDrawing a display list = native code only\n\n
- #68 A DisplayList can reference other DisplayLists\nNote that only one DisplayList is rebuilt, nothing else is touched!\nMuch less code is executed\nDrawing a display list = native code only\n\n
- #69 A DisplayList can reference other DisplayLists\nNote that only one DisplayList is rebuilt, nothing else is touched!\nMuch less code is executed\nDrawing a display list = native code only\n\n
- #70 A DisplayList can reference other DisplayLists\nNote that only one DisplayList is rebuilt, nothing else is touched!\nMuch less code is executed\nDrawing a display list = native code only\n\n
- #71 A DisplayList can reference other DisplayLists\nNote that only one DisplayList is rebuilt, nothing else is touched!\nMuch less code is executed\nDrawing a display list = native code only\n\n
- #72 A DisplayList can reference other DisplayLists\nNote that only one DisplayList is rebuilt, nothing else is touched!\nMuch less code is executed\nDrawing a display list = native code only\n\n
- #73 A DisplayList can reference other DisplayLists\nNote that only one DisplayList is rebuilt, nothing else is touched!\nMuch less code is executed\nDrawing a display list = native code only\n\n
- #74 A DisplayList can reference other DisplayLists\nNote that only one DisplayList is rebuilt, nothing else is touched!\nMuch less code is executed\nDrawing a display list = native code only\n\n
- #75 A DisplayList can reference other DisplayLists\nNote that only one DisplayList is rebuilt, nothing else is touched!\nMuch less code is executed\nDrawing a display list = native code only\n\n
- #76 A DisplayList can reference other DisplayLists\nNote that only one DisplayList is rebuilt, nothing else is touched!\nMuch less code is executed\nDrawing a display list = native code only\n\n
- #77 A DisplayList can reference other DisplayLists\nNote that only one DisplayList is rebuilt, nothing else is touched!\nMuch less code is executed\nDrawing a display list = native code only\n\n
- #78 A DisplayList can reference other DisplayLists\nNote that only one DisplayList is rebuilt, nothing else is touched!\nMuch less code is executed\nDrawing a display list = native code only\n\n
- #79 A DisplayList can reference other DisplayLists\nNote that only one DisplayList is rebuilt, nothing else is touched!\nMuch less code is executed\nDrawing a display list = native code only\n\n
- #80 A DisplayList can reference other DisplayLists\nNote that only one DisplayList is rebuilt, nothing else is touched!\nMuch less code is executed\nDrawing a display list = native code only\n\n
- #81 A DisplayList can reference other DisplayLists\nNote that only one DisplayList is rebuilt, nothing else is touched!\nMuch less code is executed\nDrawing a display list = native code only\n\n
- #82 A DisplayList can reference other DisplayLists\nNote that only one DisplayList is rebuilt, nothing else is touched!\nMuch less code is executed\nDrawing a display list = native code only\n\n
- #83 A DisplayList can reference other DisplayLists\nNote that only one DisplayList is rebuilt, nothing else is touched!\nMuch less code is executed\nDrawing a display list = native code only\n\n
- #84 A DisplayList can reference other DisplayLists\nNote that only one DisplayList is rebuilt, nothing else is touched!\nMuch less code is executed\nDrawing a display list = native code only\n\n
- #85 A DisplayList can reference other DisplayLists\nNote that only one DisplayList is rebuilt, nothing else is touched!\nMuch less code is executed\nDrawing a display list = native code only\n\n
- #86 A DisplayList can reference other DisplayLists\nNote that only one DisplayList is rebuilt, nothing else is touched!\nMuch less code is executed\nDrawing a display list = native code only\n\n
- #87 A DisplayList can reference other DisplayLists\nNote that only one DisplayList is rebuilt, nothing else is touched!\nMuch less code is executed\nDrawing a display list = native code only\n\n
- #88 A DisplayList can reference other DisplayLists\nNote that only one DisplayList is rebuilt, nothing else is touched!\nMuch less code is executed\nDrawing a display list = native code only\n\n
- #89 Let&#x2019;s examine what happens when enabling WiFi in Settings\nWe&#x2019;re going to tap the Wi-Fi list item and look at what happens in both models\n\n
- #90 Let&#x2019;s examine what happens when enabling WiFi in Settings\nWe&#x2019;re going to tap the Wi-Fi list item and look at what happens in both models\n\n
- #91 Let&#x2019;s examine what happens when enabling WiFi in Settings\nWe&#x2019;re going to tap the Wi-Fi list item and look at what happens in both models\n\n
- #92 Let&#x2019;s examine what happens when enabling WiFi in Settings\nWe&#x2019;re going to tap the Wi-Fi list item and look at what happens in both models\n\n
- #93 Let&#x2019;s examine what happens when enabling WiFi in Settings\nWe&#x2019;re going to tap the Wi-Fi list item and look at what happens in both models\n\n
- #94 When the selector turns blue, here are all the views that need to redraw\nEach View executes all of its Java drawing logic\nLot of code!\n
- #95 With the new model, only one piece of Java code is executed\nDrawing display lists is done in native\nOnly a series of draw calls, no logic whatsoever\n
- #96 If you change a View, call invalidate() on it\nDO NOT rely on calling invalidate() on a parent or sibling\nIt may have worked before, it won&#x2019;t anymore\nIt was incorrect before, but worked anyway\n
- #97 In the old model, invalidate()ing a View meant redrawing intersecting Views (children for instance)\nNotice how both leaves are drawn even though they are not dirty\n
- #98 In the old model, invalidate()ing a View meant redrawing intersecting Views (children for instance)\nNotice how both leaves are drawn even though they are not dirty\n
- #99 In the old model, invalidate()ing a View meant redrawing intersecting Views (children for instance)\nNotice how both leaves are drawn even though they are not dirty\n
- #100 In the old model, invalidate()ing a View meant redrawing intersecting Views (children for instance)\nNotice how both leaves are drawn even though they are not dirty\n
- #101 In the old model, invalidate()ing a View meant redrawing intersecting Views (children for instance)\nNotice how both leaves are drawn even though they are not dirty\n
- #102 In the old model, invalidate()ing a View meant redrawing intersecting Views (children for instance)\nNotice how both leaves are drawn even though they are not dirty\n
- #103 In the old model, invalidate()ing a View meant redrawing intersecting Views (children for instance)\nNotice how both leaves are drawn even though they are not dirty\n
- #104 In the old model, invalidate()ing a View meant redrawing intersecting Views (children for instance)\nNotice how both leaves are drawn even though they are not dirty\n
- #105 In the old model, invalidate()ing a View meant redrawing intersecting Views (children for instance)\nNotice how both leaves are drawn even though they are not dirty\n
- #106 In the old model, invalidate()ing a View meant redrawing intersecting Views (children for instance)\nNotice how both leaves are drawn even though they are not dirty\n
- #107 In the old model, invalidate()ing a View meant redrawing intersecting Views (children for instance)\nNotice how both leaves are drawn even though they are not dirty\n
- #108 In the old model, invalidate()ing a View meant redrawing intersecting Views (children for instance)\nNotice how both leaves are drawn even though they are not dirty\n
- #109 In the old model, invalidate()ing a View meant redrawing intersecting Views (children for instance)\nNotice how both leaves are drawn even though they are not dirty\n
- #110 In the old model, invalidate()ing a View meant redrawing intersecting Views (children for instance)\nNotice how both leaves are drawn even though they are not dirty\n
- #111 In the old model, invalidate()ing a View meant redrawing intersecting Views (children for instance)\nNotice how both leaves are drawn even though they are not dirty\n
- #112 In the old model, invalidate()ing a View meant redrawing intersecting Views (children for instance)\nNotice how both leaves are drawn even though they are not dirty\n
- #113 In the new model, invalidating a parent redraws that parent only\nNote how the children are not redrawn\n\n
- #114 In the new model, invalidating a parent redraws that parent only\nNote how the children are not redrawn\n\n
- #115 In the new model, invalidating a parent redraws that parent only\nNote how the children are not redrawn\n\n
- #116 In the new model, invalidating a parent redraws that parent only\nNote how the children are not redrawn\n\n
- #117 In the new model, invalidating a parent redraws that parent only\nNote how the children are not redrawn\n\n
- #118 In the new model, invalidating a parent redraws that parent only\nNote how the children are not redrawn\n\n
- #119 In the new model, invalidating a parent redraws that parent only\nNote how the children are not redrawn\n\n
- #120 In the new model, invalidating a parent redraws that parent only\nNote how the children are not redrawn\n\n
- #121 In the new model, invalidating a parent redraws that parent only\nNote how the children are not redrawn\n\n
- #122 In the new model, invalidating a parent redraws that parent only\nNote how the children are not redrawn\n\n
- #123 In the new model, invalidating a parent redraws that parent only\nNote how the children are not redrawn\n\n
- #124 In the new model, invalidating a parent redraws that parent only\nNote how the children are not redrawn\n\n
- #125 In the new model, invalidating a parent redraws that parent only\nNote how the children are not redrawn\n\n
- #126 In the new model, invalidating a parent redraws that parent only\nNote how the children are not redrawn\n\n
- #127 In the new model, invalidating a parent redraws that parent only\nNote how the children are not redrawn\n\n
- #128 In the new model, invalidating a parent redraws that parent only\nNote how the children are not redrawn\n\n
- #129 In the new model, invalidating a parent redraws that parent only\nNote how the children are not redrawn\n\n
- #130 We briefly mentioned layers earlier, for compatibility\nBut layers can do much more, they are very useful and efficient\nThe option Paint can be used to control compositing\n
- #131 Even with display lists, drawing is expensive\nA display list can have many operations\nAnimating a View requires to rerun these operations on every frame\nAnimating complex Views can be more efficient\n
- #132 With a layer (or offscreen cache/bitmap), drawing happens once (or when the view invalidates)\nOnly the layer is drawn on screen, it&#x2019;s just a texture\nIt&#x2019;s *very* efficient, especially for the GPU\nAnd layers have other advantages too\n
- #133 The type of layer LAYER_TYPE_NONE disables caching\nDefault value, View is not backed by an off-screen buffer\n
- #134 The View is rendered into a Bitmap, just like setDrawingCacheEnabled(true)\nForces software rendering, good for compatibility\nExpensive to refresh a software layer (sw rendering + texture upload)\nUse only if necessary! (costs Dalvik heap memory!!!!)\n\n
- #135 The View is rendered into an FBO, using OpenGL/HW acceleration\nReally fast, costs only GPU memory\nOptimized for blending\n
- #136 Hardware layers render View into a hardware texture\nDrawing code runs only when View.invalidate() is called\nSome animations are applied directly onto the layer\n
- #137 Perf comparison of \nDrawing a hardware layer is much faster, recommended when animating a complex View\nBut layers cost memory and refreshing a layer costs 2x the fillrate\n
- #138 Use the optional Paint to apply visual treatments:\nopacity, color filter, blending modes etc.\nYou can tint a view, make it grayscale, etc.\n
- #139 Launcher modified to display the icons in gray\nThe pages of icons are backed by hardware layers\nVery easy to do\n
- #140 Here is the code used in the previous screenshot\nJust sets a ColorFilter on the paint used by the hardware layer\nEasy!\n
- #141 Forces a View to render in software\nWorkaround for hw limitations or GL pipeline limitations\n
- #142 Related to performance, but worth talking about in detail\nSome View properties affect layers directly, which make them very cheap\n
- #143 When changing one of these properties, the View does not invalidate\nThe layer is not redrawn, instead the parent&#x2019;s DisplayList is updated\nThis is a very efficient way to animate Views\nThese properties are also DisplayLists friendly\n
- #144 When setting one of these properties, the parent is invalidated, and the parent&#x2019;s DisplayList is dirtied\nRebuilding the parent&#x2019;s display list is usually very cheap, since it refers to DisplayLists/Layers\n
- #145 When setting one of these properties, the parent is invalidated, and the parent&#x2019;s DisplayList is dirtied\nRebuilding the parent&#x2019;s display list is usually very cheap, since it refers to DisplayLists/Layers\n
- #146 When setting one of these properties, the parent is invalidated, and the parent&#x2019;s DisplayList is dirtied\nRebuilding the parent&#x2019;s display list is usually very cheap, since it refers to DisplayLists/Layers\n
- #147 When setting one of these properties, the parent is invalidated, and the parent&#x2019;s DisplayList is dirtied\nRebuilding the parent&#x2019;s display list is usually very cheap, since it refers to DisplayLists/Layers\n
- #148 When setting one of these properties, the parent is invalidated, and the parent&#x2019;s DisplayList is dirtied\nRebuilding the parent&#x2019;s display list is usually very cheap, since it refers to DisplayLists/Layers\n
- #149 When setting one of these properties, the parent is invalidated, and the parent&#x2019;s DisplayList is dirtied\nRebuilding the parent&#x2019;s display list is usually very cheap, since it refers to DisplayLists/Layers\n
- #150 Here is a simplified version of the parent&#x2019;s display list\nDoes NOT execute() viewB.draw()\n
- #151 Here is a simplified version of the parent&#x2019;s display list\nDoes NOT execute() viewB.draw()\n
- #152 Here is a simplified version of the parent&#x2019;s display list\nDoes NOT execute() viewB.draw()\n
- #153 If you want to animated a complex View (a ListView for instance), use layers\nThis is an example of a 3D rotation optimized with layers\nBut layers are costly to maintain (memory, refresh/fillrate)\n
- #154 Keep layers only for the duration of the animation\nEasy to do with an AnimatorListener\nSaves time and space\n
- #155 The new rendering pipeline changes the way rendering works\nIt&#x2019;s still an immediate mode\nBut with a special kind of caching\n
- #156 The more views you have, the longer is takes to draw\nViewGroups in particular are very costly\nKeep your hierarchy flat\n
- #157 Changing the alpha of a View costs 2x the fillrate, if you are not using layers\nAvoid it on large views (half the size of the screen) or make sure you use hardware layers\n
- #158 Do NOT create Paints, Bitmaps, Shaders, etc. in draw methods\nCreating new ones is costly and will defeat internal caches and optimizations\nIt also avoids unnecessary GCs\n
- #159 Changing a Bitmap, even one pixel, is expensive\nIt will cause a texture upload, which is a copy to GPU memory\nAvoid doing it if you can\n
- #160 Paths are rendered using texture\nChanging a path causes the generation of an offscreen bitmap, software rasterization and texture upload\n
- #161 On current hardware, no more than 2.5x times the entire screen\nRemove obscured views (useless background bitmap for instance)\n
- #162 Profile profile profile\nWe&#x2019;ve spent weeks profiling our code to optimize it on tablets\nNasty surprises sometimes (new bitmaps created on every frame, etc.)\nAlways profile your code before blaming someone else!\n
- #163 \n
- #164 \n
- #165 \n