I'm experiencing very janky scrolling of a LazyCol...
# compose-desktop
r
I'm experiencing very janky scrolling of a LazyColumn with my mouse wheel. It looks like sometimes the animation is skipped, and the content jumps? It seems particularly bad when changing directions. I've attached a video showing compose scrolling (janky) vs. native scrolling (smooth) Does anyone have any ideas how to fix this?
Example code:
Copy code
@Composable fun Example() {
    Box {
        val lazyListState = rememberLazyListState()

        LazyColumn(state = lazyListState) {
            items(99) {
                val color = when (it % 7) {
                    0 -> Color.Red
                    1 -> Color.Blue
                    2 -> Color.Green
                    3 -> Color.Yellow
                    4 -> Color.Magenta
                    5 -> Color.Gray
                    6 -> Color.Cyan
                    else -> Color.Transparent
                }
                Row(
                    modifier = Modifier
                        .fillMaxWidth()
                        .padding(12.dp),
                    verticalAlignment = Alignment.CenterVertically,
                ) {
                    Box(modifier = Modifier.size(40.dp).background(color))
                    Spacer(modifier = Modifier.width(12.dp))
                    BasicText("Item number $it")
                }
            }
        }

        VerticalScrollbar(
            modifier = Modifier.align(Alignment.CenterEnd).fillMaxHeight(),
            adapter = rememberScrollbarAdapter(scrollState = lazyListState)
        )
    }
}
c
Hmm does adding a key help?
👍 1
r
@Chris Sinco [G] unfortunately not. Added a key as follows:
Copy code
items(99, key = { it }) {
But the scrolling issue remains
Does anyone have any ideas on how to address this? Perhaps disabling mouse-wheel scrolling and implementing it manually?
m
Does that remains on production builds?
r
@Messias Junior can you define a production build? I see no change when building with my release configuration
I'm inclined to think this is perhaps a bug in the scroll animation code, rather than a performance issue?
@Ivan Matkov it looks like perhaps you worked on the implementation of smooth scrolling? Do you have any ideas about how I might be able to solve this?
i
What version of Compose do you use? Does it behave the same in last beta? Does it laggy during animation from the app code instead of input/mouse triggered one?
r
Hi Ivan! • I'm using compose multiplatform 1.6.2. • The animation is smooth when animating the list using
lazyListState.animateScrollToItem(...)
• It feels like this isn't a lag/performance issue. My guess would be that the scroll animation via mouse wheel sometimes gets cancelled, causing the list's y offset to suddenly change. • Trying the latest beta now :)
Same issue on the latest beta.
🤔 1
👀 1
Capture from latest beta
i
Cannot reproduce this (1.6.10-beta02, Windows 10)
Asked teammates to try too
🙌 1
r
Do you have mouse wheel "free scrolling" on? Or stepping, where it scrolls N lines per click of the wheel (this is what I have). Best repro for me is to slowly scroll about quickly and then do a single mouse-wheel up. About 25% it enters this no-animation state
I'm using Windows 11 (up-to-date)
Mouse settings
i
Stepping, confirmed by logging events. I wanted to record logs console too, but Win10 tool is kinda very limited here
r
More debug info: • If I scroll only 1 "step" at a time, the issue never happens. It always animates. • If I scroll more than 1 step at a time, the issue is likely to happen.
Looking at mouse wheel events in the browser: • When I scroll 1 step it's always a 108.0 delta • When I scroll more than 1 step it's a non-integer delta, e.g. 231.29999999999998
One step at a time vs. multiple steps
i
non-integer delta should be ok - it's always the case for macos touchpad (it emulates wheel events by OS)
👍 1
Checked by 2 more people: it works as it should. Since there were changes in this place between 1.6.2 and 1.6.10, let's re-check/confirm that resolved version of Compose in your project is up-to-date. What's the output of
dependencies
gradle task?
👍 1
r
Here's my output of :dependencies
👀 1
1
i
Okay, thanks. Out of ideas for now. And without local reproduction to debug it's hard to say what's wrong here 🙁
r
Hmmm, is there any debug info/logging I can capture that might help with this?
🤔 1
i
Since Compose is open-source the most efficient way to debug it locally/add additional logs in suspicious places. If you are ready to play with Compose's source code - I can point where this animation logic happens
u
Just my two cents - I'm failing to reproduce it (nevermind the title) may be you'll see something amiss on this screen recording
r
Thanks for trying a repro Shagen! In your video, your scrolling speed is fast enough that you might not notice if the animation doesn't work. The best repro for me is to scroll about quickly, then scroll gently, one "step" at a time.
Additional debug info: If I render the value of
lazyListState.isScrollInProgress
, I can see that when the bug occurs, the state flickers immediately from false->true->false very quickly. When the animation runs correctly, the transition is much slower.
🤔 2
i
ok, I guess I found the reason
r
@Ivan Matkov happy to debug, I'll try getting a forked repo working. Any source files I should look at in particular?
❤️ 1
This check is about detecting trackpad - it's already "smooth" and the animation there just causes extra input lag. AWT doesn't provide this information about device directly, so it's about heuristic from
preciseWheelRotation
field. Based on info about non-integer delta you posted, I guess this one sometimes false-positive.
r
That sounds right!
It looks like the heuristic is used to disable animation when using a "free" scrolling wheel. This doesn't match WinUI behaviour, where scrolling always animates, even in "free" scroll mode
But we need some time to properly re-check this, don't expect the fix in upcoming release
Thanks for reporting and collaboration ❤️
r
Amazing!
Thank you so much. Feel free to ping me if you'd like more debugging/verification of the fix -- happy to help!
👍 1