Is there some documentation about the "cost" of adding wrappers to composable? For example in a Column I want to have a Text in the middle with weight to fit all the remaining space. Seems it's impossible to directly center vertically the text, and the simple solution is to wrap the Text in a Row. But since before Compose the rule was always to avoid adding nesting for things likes that, it sounds like bad when maybe it just have 0 impact and is actually the perfect solution.

Maybe this quote from docs may help:

In the View system,

ConstraintLayout

was the recommended way to create large and complex layouts, as a flat view hierarchy was better for performance than nested views are. However, this is not a concern in Compose, which is able to efficiently handle deep layout hierarchies.

(source)

I've always heard that about Views but I've never noticed any real performance issues in my 5 years of Android dev 🤷‍♂️

Thanks so I guess it's minimal and Row is the correct answer 🙂 @Brian G there was quite a few case where it was the case specially on complex screens with textview updates.

@Brian G google improved it a lot s few years ago

If you'd like to center a single element it's probably easier to use

.wrapContent[Width|Height|Size]

at the end of that element's modifier chain than to add a row or column around it. Performance-wise both will be in similar ballparks.

Thanks, did not found this one.

@Brian G The real cost of nesting Views comes from nesting multi-pass layouts (linear layouts with weights for instance). This can create an exponential increase in the number of measurements. There are a number of optimizations in Views to address this, but in general it's best to avoid this setup if you can.

right. that plus the more naive invalidation of layouts in Views creates a storm of work for view measurement to do.

@Tolriq yes, this issue is fixed and expected in beta08. see https://issuetracker.google.com/issues/188566058 for details

Thanks mine is a little different as the missing part instantly appears after scrolling by just 1px (and from logs without composing the rows they where prepared just non visible). Will wait for B8 before investigating and report more.

right, then you faced https://issuetracker.google.com/issues/188981591 which was also fixed for beta08

Nice then since you are here, a known issue about fling? randomly after fling to top or bottom then the next fling in opposite direction will not work and only scroll by a limited amount. (Sorry to ask here, just starting played today with Compose and the issue tracker is huge without knowing all the proper terms for stuff)

no, I am not aware about this one. please file a bug, especially if you can share a reproducible sample

Will do when a little more confident about what I'm doing 🙂 Thanks for the info.

I have the same issue with fling, just using normal vertical scroll modifier

@Tolriq @Brian G Sorry, I know it’s been a while, but any update on this?