Confirmed users
158
edits
B2G/Wifi Display: Difference between revisions
Jump to navigation
Jump to search
→Approach 2 (Layer-based)
| Line 65: | Line 65: | ||
==== Approach 2 (Layer-based) ==== | ==== Approach 2 (Layer-based) ==== | ||
The layer-based approach would traverse the layer tree twice with difference transform matrix and request the GPU to draw on different EGLSurface respectively. We implement this approach like the following figure suggests: in each CPU/GPU frame processing cycle, there is a run for the "primary display" followed by the "virtual display" run. The consumer of GPU in the "virtual display" run is the encoder instead of HWComposer/FrameBuffer. Other than that, most of the operations are identical in the two runs. | |||
[[File:Miracast pipeline.png|1000px]] | [[File:Miracast pipeline.png|1000px]] | ||
We tested on flame v188 and nexus 4 KK. Statistics showed the fps can still reach 60 on nexus 4 but less than 20 on flame. After profiling each stage of the frame processing, we found that eglSwapBuffer took too much time in the virtual display run. This might be due to the poor codec power on flame. Take Frame 2' as the example. Even if Frame 2' is complete before the next scheduled Render() task, we might still need to wait for the encoder to consume the frame and cause the compositor thread blocked. | |||
[[File:Miracast pipeline jank.png|1000px]] | [[File:Miracast pipeline jank.png|1000px]] | ||
To mitigate the blocking issue, parallizing the sequential two runs of rendering/swapping might help. However, it will introduce the synchronization and threading issues and we still have no time to investigate it yet. | |||
== Profiling and Investigation == | == Profiling and Investigation == | ||
== TODOs == | == TODOs == | ||