Menu
From the Android Threads doc:
you must not manipulate your UI from a worker thread—you must do all manipulation to your user interface from the UI thread
So I believe that everything on the screen is rendered by the UI thread. But in Android Lollipop they have introduced a RenderThread:
A new system-managed processing thread called RenderThread keeps animations smooth even when there are delays in the main UI thread
How does it work? Does the RenderThread use the UI thread to render animations (Views with new properties) on the screen? If so, why doesn't it block the UI thread?
707
An easy way to think about it is the main thread is setting up the list of things to render, and the render thread is packaging that list up and telling the graphics API (and thus the GPU) explicitly when and how to render it. The most you get in terms of insight into what the GPU is doing from there is if Gfx.
Render thread is a component that has been introduced in Android Lollipop. It takes the inputs from UI thread and handles them to GPU . We assume that UI thread and Render thread work sequentially because render thread doesn't know what to do without the inputs from UI thread.
User Interface Thread or UI-Thread in Android is a Thread element responsible for updating the layout elements of the application implicitly or explicitly. This means, to update an element or change its attributes in the application layout ie the front-end of the application, one can make use of the UI-Thread.
Typically, WPF applications start with two threads: one for handling rendering and another for managing the UI. The rendering thread effectively runs hidden in the background while the UI thread receives input, handles events, paints the screen, and runs application code.
The RenderThread depends on the UI Thread but it does run in parallel along with the last mentioned one.
Its main job is to run expensive computation on the GPU in order to empty the heavy load of the UI Thread.
How does it work?
Basically, the UI Thread acts as a job dispatcher. It prepares a pipeline of commands to be executed on the RenderThread.
The GPU doesn't know what an animation is; it can only understand basic commands, e.g:
translation(x,y,z)rotate(x,y)or basic drawing utilities:
drawCircle(centerX, centerY, radius, paint)drawRoundRect(left, top, right, bottom, cornerRadiusX, cornerRadiusY, paint) Combined together they form the complex animation you see on the screen.
Does the RenderThread use the UI thread to render animations (Views with new properties) on the screen?
No, it runs asynchronously
If so, why doesn't it block the UI thread?
The docs explain that the rendering is performed in two phases:
View#draw -> UI Thread
DrawFrame -> RenderThread, which performs work based on the View#draw phase.On a lower level, when using hardware acceleration, the deferred rendering is executed by a DisplayListCanvas.
In this Canvas implementation you can find the aforementioned drawing commands, such as drawCircle.
As such, the DisplayListCanvas is also the drawing target of the RenderNodeAnimator, which runs the basic animation commands (translate, scale, alpha, ...).
199
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
