https://kotlinlang.org logo
#compose
Title
# compose
t

Tolriq

05/25/2021, 2:25 PM
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.
f

Filip Wiesner

05/25/2021, 2:27 PM
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)
b

Brian G

05/25/2021, 2:30 PM
I've always heard that about Views but I've never noticed any real performance issues in my 5 years of Android dev 🤷‍♂️
t

Tolriq

05/25/2021, 2:32 PM
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.
j

Javier

05/25/2021, 2:33 PM
@Brian G google improved it a lot s few years ago
a

Adam Powell

05/25/2021, 2:38 PM
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.
t

Tolriq

05/25/2021, 2:46 PM
Thanks, did not found this one.
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)
r

romainguy

05/25/2021, 3:15 PM
@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.
a

Adam Powell

05/25/2021, 3:20 PM
right. that plus the more naive invalidation of layouts in Views creates a storm of work for view measurement to do.
@Tolriq I think we were tracking a bug or two in beta07 around something like that, @Andrey Kulikov would know the details
a

Andrey Kulikov

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

Tolriq

05/25/2021, 3:27 PM
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.
a

Andrey Kulikov

05/25/2021, 3:34 PM
right, then you faced https://issuetracker.google.com/issues/188981591 which was also fixed for beta08
t

Tolriq

05/25/2021, 4:24 PM
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)
a

Andrey Kulikov

05/25/2021, 4:29 PM
no, I am not aware about this one. please file a bug, especially if you can share a reproducible sample
t

Tolriq

05/25/2021, 5:00 PM
Will do when a little more confident about what I'm doing 🙂 Thanks for the info.
b

Brian G

05/25/2021, 8:19 PM
I have the same issue with fling, just using normal vertical scroll modifier
j

John Ugwuadi

07/25/2021, 7:09 PM
@Tolriq @Brian G Sorry, I know it’s been a while, but any update on this?
3 Views