Are the performances of Compose in a ViewGroup (passed to `setContentView` in an Activity) the same ...

# compose

[louiscad]

Are the performances of Compose in a ViewGroup (passed to setContentView in an Activity) the same as Compose at the root of an Activity, or is there layout render node related optimizations or whatever that cannot take place when Compose is used in a ViewGroup?

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

ComponentActivity.setContent just creates an AndroidComposeView and sets it as the activity’s content view, so it doesn’t look like there’s any difference.

https://cs.android.com/androidx/platform/frameworks/support/+/androidx-master-dev:compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/Wrapper.kt;l=156?q=ComponentActivity.setContent

[romainguy]

It shouldn’t matter

[louiscad]

I need to figure out what that AndroidOwner is now… I mean, tomorrow or later after I sleep 😅

[romainguy]

The “root” of an Activity is not the root at all

[romainguy]

There’s the DecorView around and who knows what else

[romainguy]

And those root views don’t do any magic anyway, only ViewRootImpl does

[louiscad]

Yes, I knew about DecorView, but since I don't know anything about the layout render nodes you mentioned in the past, I was thinking it was an alternative to Views, and Compose could bypass android.view.View altogether.

[romainguy]

No, the render nodes (display lists before that) are just a lower level construct that Views used for rendering

[romainguy]

(and Compose uses them too)

[louiscad]

What is that condition trying to do in the code of setContent that Zach linked?
Is it a sort of caching?

[louiscad]

Is it more efficient than just calling the following?
setContentView(AndroidComposeView(this).view, DefaultLayoutParams)

[louiscad]

I'm asking that for interoperability concerns in apps using both Splitties Views DSL (views with code) and Compose. If I can treat a Compose view like a plain View that I can simply give to setContentView or put in any ViewGroup with some layout params, without specific gotchas that need to "leak" implementation details at use site, that'll be quite helpful.

[romainguy]

There’s a bit more happening to enable inspection, ensuring the frame manager is up and running, etc.

[romainguy]

You should really use the APIs we provide, ViewGroup.setContent and ComponentActivity.setContent

[Adam Powell]

well, maybe not ViewGroup.setContent - prefer using ComposeView and AbstractComposeView for compose content 🙂

[Adam Powell]

eventually we're going to merge those with the internal AndroidComposeView so that it's all the same thing and remove ViewGroup.setContent - the latter only works in terms of a single View child of the ViewGroup receiver and as such it doesn't quite fit right