var thresholdProgress: Float by rememberSaveable(uiState.thresholdProgress) {
        mutableStateOf(uiState.thresholdProgress)
    }
            Slider(
                value = thresholdProgress,
                onValueChange = {
                    thresholdProgress = it
                    viewModel.onThresholdProgressChanged(it)
                },
            )

fun onThresholdProgressChanged(progress: Float) {
        val progressStep = (progress * 100).roundToInt()
        val lux = if (progressStep <= 50) {
            progressStep
        } else {
            50 + (progressStep - 50) * 5
        }
        _uiState.update { it.copy(lux = lux) }
    }

uiState.lux

is used for continuously updating the lux number in the UI as user drags the slider.

So you observe the

uiState.lux

in UI and update the

thresholdProgress

MutableState?

Could it be that when uiState updates, a larger portion of the screen is recomposed as well?

From

uiState.lux

I only update the LUX value in the text field

Can you share the entire code for the (what looks like) bottom sheet?

It would be a lot of copy paste 😉 Yes, it is a

ModalBottomSheetLayout

Is uiState only observed in the sheetContent?

Yes

Can you temporarily remove all the other composables from the sheet besides the slider? Does it still lag?

It doesn't lag when I outcomment the line updating the

uiState.lux

from the callback

Hmm, in your

rememberSaveable(uiState.thresholdProgress)

I think youre creating a new mutableState everytime the progress changes

Yes, but the

thresholdProgress

in the ViewModel is only updated when I load the data from API when creating the bottom sheet for the first time. The value in the ViewModel is not updated while dragging the slider.

You could try using this on the other composables in the sheet, it will highlight whenever they recompose.. and if stuff is flashing like crazy, thats probably it 🙂

Hmm, I think Dolphin also had something like this built in...

I worked with a pretty similar case recently where a slider in my app lagged behind. I eventually solved it by really limiting the recomposition scope of it, now its the only thing that recomposes, and its super snappy!

Android Studio Dolphin, sorry

There is a similar problem mentioned on Stack Overflow (without an answer) https://stackoverflow.com/questions/69394091/jetpack-compose-slider-performance

I have zero experience with LiveData unfortunately! If its not too much work, you could try replacing it with MutableState just to verify whether or not thats where the bottleneck is 🙂

This is someone else's issue, I use StateFlow observed as MutableState

Gotcha, thats good 👍🏽 Id say try the recomposition tracking I mentioned earlier then, I still believe thats the root cause. You can also set the slider increments to a larger number to get a little fewer updates, but thats probably not what you really want?

I just checked recomposition tracking and there's no flashing at all.

So try

valueRange = 0f..100f

and

steps = 99

. (Endpoints would be 0, 100 which I think matches what you have now.) If you use the Material3 version of slider you’ll get fewer callbacks (only on the “integer” ticks...I say “integer” because they’re floats and may be ever so slightly off the integer marks).

I just tried it. I think the Slider was not designed for such a high number of steps. It makes tiny "jumps" between each step. The movement is snappier, but it's jerky.

I just tried a Material 3 Slider with 100 steps and it seems to move OK, even in a debug build (of course I only have a Slider and not your entire screen). With a discrete Material 3 Slider there will be little discrete jumps, which may not be what you want. My colors are also OK. FWIW, even the Material 2 version moves OK, though I see it has more callbacks.

I use Material 2

If you add this right next to the slider, how many calls do you get if you move the slider one step?

SideEffect { 
    Log.d("TAG", "Recomp")
}

It won't log the slider recomposition, only of the containing composable...

I think they share the same recomposition scope, no?

Slider recomposition would have to be logged inside the

Slider

Can you please share the code that surrounds the slider, including where uiState is collected?

That's really a lot of code if you want the whole context

Thank you! I think the problem is that youre collecting the uiState at the root of the composables, so everytime it updates, pretty much everything else is forced to recompose as well. As a rather quick experiment, you could try passing the viewmodel to SystemScreen, then to SensorSettingsSheet, and collect the value there instead - that should help a lot!

I thought only the parts of the composable where the

uiState

value actually changes get recomposed...

Another thing that comes to mind, if uiState is immutable you could annotate it with @Immutable as well, that will help compose be smarter about what it recomposes too 🙂

I tested

@Immutable

and the slider is still as laggy as it was

I cant say that I fully understand how compose handles recompositions, but in most cases you dont need to think too much about these things, it just works. This is a great article on the subject.

Yes, in my experience it also just works usually, apart from cases like this...

Im confident that the viewmodel solution I mentioned will work wonders. Im just about out of time now, good luck - and Ill respond again later if you have any further questions 🙂

Thank you again, that's very kind of you! 🙏

If you really need to defer state reads to a composable down the line (and don’t want to pass viewmodels like you’re saying here) you’ll have to pass down lambdas that read the state, something like here. If you call a composable which takes in a parameter, even if you’ve got it backed inside a State object, in order to call that function you’re implicitly calling .value on it, therefore invalidating the current scope. If you instead pass it inside a lambda you’re then not reading it in that scope and can defer the reading into as small scope as possible.

Ah, sorry I dont use viewmodels so I didnt know that was a thing. Id say you can do one of two things; 1. Do the

uiState.collectAsState()

like you currently are, but replace 'by' with '=' so that you get a State<UiState>. Pass it to the inner composables, like I mentioned with viewmodel, but only read (state.value) its value where youre also using it. 2. Pass uiState (the stateflow) down the composables instead, and collectAsState() where you also read the value 🙂

Oh yes, both your and @Stylianos Gakis’s solutions seem like exactly what I need! This way I can indeed defer reading the state to the actual composable that uses it and probably still easily create previews by just creating

mutableStateOf(MyUiState(...))

. BTW if you don't use viewmodels, what do you use? Do you just keep the whole state in the composable itself?

👍🏽 I use something completely custom 😄 The same principles apply where composables just get some state that they render. If you want, you can take a look at this library; its not what I use but the concept is similar.

Awesome, thank you both for the time and help, and explaining everything very clearly along the way!

Just before you invest too much into passing such parameters, take a look at Adam’s suggestions here https://kotlinlang.slack.com/archives/CJLTWPH7S/p1650307495136109?thread_ts=1650289906.051689&amp;cid=CJLTWPH7S and strongly consider what it is that he is suggesting here.

Oh yes, the deferred read via lambda looks indeed much better

Yeah but the idea is that you don't need to do that most of the time. And always this isn't about improving correctness, just performance. You can get correct output without knowing any of this, which is the important bit imo.

Yes, true. But if you don't understand very deeply how it works, then such performance issues are a brick wall. If it weren't for you and @Zoltan Demant I wouldn't figure it out on my own (unless I would spend a week reading Compose documentation and experimenting with sample apps).

To be fair however, if one hits a performance road block, I'd guess they'd go to the official docs about how to improve performance, on the doc part named exactly "performance" https://developer.android.com/jetpack/compose/performance. And said documentation explains with an imo quite clear example how you can defer those reads https://developer.android.com/jetpack/compose/performance#defer-reads to improve performance. I agree that the community here is amazing and I've gotten an immense amount of help myself too, but the more I read the docs the more I realize they're in general incredibly well written.

Definitely, I must admit I was amazed by the relatively easy start with Compose and skipped reading most of the documentation in the beginning because the learning curve was so easy.

ya. cases like this, if you get the input from the viewmodel and then send the output to the viewmodel which in turn feeds back in the composable, you will have an infinite recomposition chain. Just observe the writes without feeding it back in.

In this particular case there is no infinite recomposition. I was not sending the slider progress from viewmodel back to the composable. Just the recomposition scope was too big (the screen in the background got unnecessarily recomposed every time when dragging the slider).