sebmarkbage
commented
6 years ago Here is some brief info about the FB native frameworks that use it:
https://componentkit.org/docs/uses.html
https://fblitho.com/docs/asynchronous-layout
https://www.youtube.com/watch?v=83ffAY-CmL4
The main use case is for individual rows in an finite scrolling list can do their layout on a background thread and then get attached to the main surface when they're done.
An interesting note is that what makes these three interesting is that they also allow that computation to be interrupted, e.g. by forcing computation on the main thread at any given point. This ensures that they can always be coordinated with other synchronous content if needed.
Let's use this issue to track links to examples we can learn from outside of the web.
Android surfaceRedrawNeededAsync:
https://developer.android.com/reference/android/opengl/GLSurfaceView#surfaceRedrawNeededAsync(android.view.SurfaceHolder,%20java.lang.Runnable)
This is a new feature in Android O. When the framework calls this method, it is requesting a need to have a surface of an activity redrawn, but it can be done asynchronously in the background. The second parameter is a callback to call when rendering is complete.
This API is intended for scenarios such as the phone rotating during display of web content. Since Chrome does all rendering asynchronously, it is not able to draw to the surface immediately and must use the async version supplied here. On pre-Android O phones Chrome does not have this API, and so must either draw the old, cached frame (stretched to the new dimensions of the phone, which is probably ugly), or draw a solid color. For fullscreen video it actually draws solid black until rendering is complete. With Android O, the framework will wait for Chrome to draw new content so it can present atomically.