| # How software rendering works in this embedder |
| |
| All memory that is allocated for graphics surfaces on Fuchsia |
| must come from |
| [sysmem](https://fuchsia.dev/fuchsia-src/development/graphics/sysmem/concepts/sysmem). |
| |
| Normally, software rendering in the Flutter embedder uses a surface that |
| Flutter allocates itself using Skia. We don't want this default behavior |
| because we need our surface to come from sysmem. As a result we provide |
| our own callback for allocating software surfaces to the embedder (see |
| `FuchsiaAcquireSoftwareSurface`). |
| |
| [`SoftwareSurface`](https://fuchsia.googlesource.com/flutter-embedder/+/refs/heads/main/src/embedder/software_surface.cc) |
| is where we interact with sysmem to get the buffer for software rendering. |
| We then register this buffer with Flatland, getting a token that we can use |
| to turn this buffer into a Flatland image. |
| |
| The lifecycle currently goes: |
| |
| - At app startup, Flutter acquires a software surface from us. |
| - Flutter then repeatedly asks us to present that software surface. |
| Reusing the same software surface is fine from frame to frame as long as the |
| window has not been resized. |
| |
| ## Future work |
| |
| - How does window resizing work? |
| - When does Flutter acquire a new surface for software rendering? |
