Is there some documentation about the "cost" of adding wrappers to composable? For example in a Colu...

# compose

[Tolriq]

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.

[Filip Wiesner]

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)

[Andrew Neal]

https://kotlinlang.slack.com/archives/CJLTWPH7S/p1611457285180600?thread_ts=1611455299.177200&cid=CJLTWPH7S

[Brian G]

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

[Tolriq]

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.

[Javier]

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

[Adam Powell]

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.

[Tolriq]

Thanks, did not found this one.

[Tolriq]

BTW@Adam Powell is there known issue with LazyColumn and Modifier.weight(1f) ? During tests and quick scrolling I relatively often ends ups with only a part of the columns being rendered (Beta 007)

[romainguy]

@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.

[Adam Powell]

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

[Adam Powell]

@Tolriq I think we were tracking a bug or two in beta07 around something like that, @Andrey Kulikov would know the details

[Andrey Kulikov]

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

[Tolriq]

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.

[Andrey Kulikov]

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

[Tolriq]

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)

[Andrey Kulikov]

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

[Tolriq]

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

[Brian G]

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

[John Ugwuadi]

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