I feel like I am going crazy too! I have two previ...

# compose

[vide]

I feel like I am going crazy too! I have two previews with different devices sizes and Resources.getSystem().displayMetrics.widthPixels gives an inconsistent value inside the same preview. Is there something I should be aware of? Repro and screenshot in 🧵

[vide]

here's some pseudocode

@Preview(device="width=1920,height=1080")
@Composable
fun P1() {
  Resources.getSystem().displayMetrics.widthPixels // value here is 1920
    
    // multiple levels deep:
    Resources.getSystem().displayMetrics.widthPixels // value here is 3840
}

@Preview(device="width=3840,height=2160")
@Composable
fun P2() {
  Resources.getSystem().displayMetrics.widthPixels // value here is 3840
}

[vide]

@Stylianos Gakis previous thread was related to debugging this phenomenon before I realized what was causing it

[vide]

Are the previews executing in parallel and Resources.getSystem() isn't safe to call..?

[vide]

Here's a real repro:

@Preview(device = "spec:shape=Normal,width=3840,height=2160,unit=px,dpi=480")
@Composable
private fun Test1() = Text("${Resources.getSystem().displayMetrics.widthPixels}", fontSize = 100.sp)


@Preview(device = "spec:shape=Normal,width=5000,height=5000,unit=px,dpi=800")
@Composable
private fun Test2() = Column {
    Text("${Resources.getSystem().displayMetrics.widthPixels}", fontSize = 100.sp)
    Boundary()
}

@Composable
fun Boundary() {
    val a = animateFloatAsState(0f)
    Text("${Resources.getSystem().displayMetrics.widthPixels}", fontSize = 100.sp)
}

[vide]

comment out the animateFloatAsState(0f) and it won't happen

[vide]

• broken on Android Studio Iguana | 2023.2.1 Canary 7
• works on Android Studio Giraffe | 2022.3.1 Patch 2
were there some changes to the preview rendering system? it feels way snappier on iguana also

[Alex Vanyo]

Resources.getSystem().displayMetrics.widthPixels is a super suspicious call. What are you trying to use that value for?

[vide]

I have a design system where the base unit is a fixed fraction of the screen width, the codebase currently uses that to try to figure out the available viewport width on initialization time. (I am aware of many reasons not to do that, but this UI is exclusively ran on embedded devices with a known set of hardware so it has not been an issue before 😅)

[Alex Vanyo]

Can you use a method that’s closer to the recommendation of caring about the specific current window size you have using WindowMetricsCalculator?

Resources.getSystem is returning something that isn’t intended to be configured for the current screen: https://developer.android.com/reference/android/content/res/Resources#getSystem()

LocalContext.current.resources.displayMetrics.widthPixels might work slightly better since it’ll be the resources for your current screen (but again in general this is something to avoid, that doesn’t take into account multi-window mode, changing displays, orientation, etc.)

[vide]

I'm kind of wary of introducing calling LocalContext.current for every single size definition from a perf perspective. It would also require adding a composable context to the helper function, meaning no more definitions outside composable contexts.

[vide]

And I don't think I can add that overhead conditionally to apply only to previews. Still would need to be a composable function invocation which probably does add some overhead on its own? And it would also break definitions outside composables. The definition is currently something like:

inline val Int.dpx get(): Dp = (this * dpxToDpMultiplier).dp

where the multiplier is global, set on based the maxWidth constraint available to the app root view at startup time (and set once per preview by a preview wrapper composable)

[vide]

I created an issue to track this further: https://issuetracker.google.com/issues/304743694