How to understand `measurement` and `intrinsic mea...

# compose

[fengdai]

How to understand measurement and intrinsic measurement?

[Adam Powell]

Measurement is, "given these width and height constraints, what size are you?" and intrinsic measurement is, "given that your width would be X, how tall would you need to be?" and the same for height/wide. Intrinsic measurement is meant to be a lighter weight alternative to full multi-pass speculative measurement to answer the same questions.

[Pablichjenkov]

It sounds like a better approach for the case when a Parent dimension is wrap_content and the Child wants to match_parent.
Is there an equivalent to:
requestLayout() and invalidate() that ones can call when the shape or content of a composable change?
Or there is no need for that?

[Adam Powell]

Intrinsic measurement is just a series of functions available that a parent can call on a measurable (child) when the parent is in its own measure or layout phases.

[Adam Powell]

as for equivalents of requestLayout and invalidate, the easiest way to get those is to change an @Model property that is read by the measure, layout or draw stages of the relevant component

[Adam Powell]

and of course, recomposing a layout or draw composable will do the trick as well.

[Adam Powell]

(with some further optimizations forthcoming along the recompose path)

[Pablichjenkov]

Got it.
I thought the fact of explicitly telling the ViewTree if you want a requestLayout or invalidate or both, optimized things a bit. Like calling only invalidate explicitly tell the system to skip measurement/layout phases.

[Adam Powell]

it does, and the @Model observation scopes perform the same duty here for triggering what phase we need to go back to

[Adam Powell]

but it puts the burden on the author of the layout and draw code to determine what data dependencies they need in each phase rather than on the author of the code that alters those data dependencies to determine how far back to invalidate

[Pablichjenkov]

I see, It makes lot of sense. Thanks

[Adam Powell]

it does mean that these things get kind of subtle for the layout/draw code author. Capturing the value of an @Model outside the scope of where you actually use it means you can end up causing more work than you intended when it changes. You want to read @Model as close to the usage site as possible.

[Pablichjenkov]

Good point