Does Compose draw each Composable directly to scre...

# compose

[Koneko Toujou]

Does Compose draw each Composable directly to screen or does it first composite each composable to a texture which ultimately ends up on screen

Eg

Row
Text

Would Compose first draw Row directly to screen, and then draw Text directly to screen

Or would Compose first draw Text to a texture, and then draw Text's texture to Row's texture, and then draw Row's texture to screen

[Zach Klippenstein (he/him) [MOD]]

Romain is probably the best person to answer this, but I can try – don’t quote me on any of this 😅. Compose works with `RenderNode`s. In general, composable structure doesn’t imply layer/rendernode structure, but layers can be introduced by certain APIs like the graphicsLayer modifier or withSaveLayer calls inside draw scopes. Composables draw to Canvas objects which are backed (in most cases, at least on newer android versions) by those `RenderNode`s. I believe there’s some relationship between a RenderNode and a display list, but i’m not sure exactly what it is.

So in your example case, Row doesn’t do anything with layers so Text would end up drawing to the same Canvas as whatever calls Row would have access to.

[Adam Powell]

Right, Compose UI tries to only draw to an intermediate rendering target if it has to, for example, if you're applying an alpha modifier to a complex composable

[Koneko Toujou]

Hmm ok

[romainguy]

And technically all drawing is done in a texture of some sort (a Surface)

[romainguy]

Android never draws directly on screen

[Koneko Toujou]

Yea

[romainguy]

But the UI toolkit tries to avoid intermediate textures as much as possible as it's expensive in terms of bandwidth.

[Koneko Toujou]

Oh ok

[romainguy]

@Zach Klippenstein (he/him) [MOD] RenderNode is basically what used to be called DisplayList. It has the same role

[Koneko Toujou]

Bandwidth as in RAM/GPU memory? Eg a 2k texture would take up around 8MB to 15 MB (depending on screen exact resolution) of memory assuming 4 bytes per pixel, eg ARBG or RGBA or however the pixel format

And thus having a lot of intermediate textures would inflate memory in proportion to how many are required and the exact size of each texture in bytes total

[romainguy]

It's not so much about how much memory would be required at any given time but how much data would have to be read/written per frame

[Koneko Toujou]

Such as copying pixels from GPU to CPU and back to GPU?

[Koneko Toujou]

Or such as drawing each texture to another texture as a quad?

Eg layering each texture on top of one another