How is it possible that when we have a scrollable regular

Column

that fills the screen with content the scrolling performance is very bad. But when we switch to an

AndroidView

that just contains a

ScrollView

and the content of the page wrapped in

LinearLayout

that contains a few

ComposeView

elements that render the same exact content as the full Compose solution, the scroll performance is much smoother. What is Compose doing in this case that is causing so much overhead?

Share the code for both…someone might be able to spot why its not as performant. (Check that youre not comparing apples to oranges by making sure this is done on a release build)

Yes its a release build, but the hardware we are using is old (10+ years) and only running Android 5.1.1. We've tried to optimize this for ages but our conclusion is that its just something inside Compose that is causing the overhead and we cannot do anything to it ourselves.

Okay makes sense. I think sharing the code here might be helpful

I dont think the code matters here, you can just imagine scrolling a page with the usual stuff: images, text, buttons, horizontal scrollers etc. Nothing special.

Well not sure what else to suggest other than, say, you might need to profile both implementations and see just where most of the UI thread time is spent.

I wish profiling would tell us something. And if it did, it would be inside Compose internals.

Scroll performance can be bad if your view recomposes a lot

We have checked, there are no unnecessary recompositions

The only way for people to help would be if you could share 2 minimal examples, maybe even video recording of both. Also if you raise an issue on the issuetracker a lot of people would +1