IssueTracker

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.compose.foundation:foundation:1.4.0-alpha03
• androidx.compose.material:material:1.4.0-alpha03
• androidx.compose.material3:material3:1.1.0-alpha03
• androidx.compose.ui:ui:1.4.0-alpha03

Yes, we have plans to make it public in the future, but it is not prioritized currently.

We don't want to globally enable this for draggable / swipeable, because the ordering can get tricky and not every component would need this, but we would explicitly add it for known components where it is required, such as in a drawer / a sheet.

Reopening this bug because we would need ModifierLocalScrollableContainer to be public so we can set it in our implementation of go/sysui-transition-layout. We have a custom gesture handler to implement transitions between different SystemUI scenes, and currently the ripple is instantly started when swiping down on clickables which has a noticeable impact on jank.

Any change this can be prioritized? :-) It looks like everything is already implement and "only" exposing a public API is missing.

Thanks for the quick reply!

For your custom gesture handler, what are the 'rules' for the transitions here - does it convert horizontal / vertical swipes past a touch slop into a transition?

Yes that's exactly what it does, using awaitHorizontalTouchSlopOrCancellation and awaitVerticalTouchSlopOrCancellation :-) We had to fork Draggable because we also needed to support multiple fingers down. See the code in http://shortn/_sm4WMJVJ8T.

@lpf any update on this by any chance? :-)

Any news? :-) Pinging this again because this is preventing us from correctling measuring performance on some of our benchmarks: when the ripple is triggered during a transition, it's causing a lot of frames to be marked as dropped. See http://shortn/_tetDF56Vt0 which compares the benchmarks without (Base) and with http://ag/26099645 (Patched).

There's work planned in this space in our general tracker, but not at a high priority compared to other ongoing work.

For the benchmark case specifically, you could still end up in cases where the ripple is triggered if the gesture is 'slow' so that the move doesn't start until after the minimum press time: what specifically is your goal here for the benchmarks?

what specifically is your goal here for the benchmarks?

I want the benchmark to be stable and have the least number of dropped frames. But we also want to make sure that in most cases this path is not triggered in production, so I don't want to just disable ripples in the benchmark either. Once we can disable the ripple inside our custom draggable, I'll make sure that the benchmark gesture is fast enough to not trigger the ripple.

FYI this is real jank, not just showing up in the benchmark.

I'll make sure that the benchmark gesture is fast enough to not trigger the ripple.

Hard to say without looking into some method traces for this, but it is likely that most of the cost isn't in drawing the ripple itself (because this is all done on the render thread), but in creating the ripple node in preparation to draw it. So even if you were to delay the interaction, it might still be slower regardless.

Do you have a link to the component with the ripple?

Not sure I understand the discussion in that bug, but it sounds like a framework issue on some API levels? Is there something actionable from the Compose side to mitigate this issue?

Friendly ping on this - note this is a clear regression from the View framework. View's are able to handle this properly.

To make sure there is no misunderstanding of the bug, here is an example that shows that the ripple is not triggered when dragging a clickable View but that is is triggered when dragging a clickable Composable :-) See the video below.

import android.widget.Button
import androidx.compose.foundation.border
import androidx.compose.foundation.gestures.draggable2D
import androidx.compose.foundation.gestures.rememberDraggable2DState
import androidx.compose.foundation.layout.Box
import androidx.compose.foundation.layout.Column
import androidx.compose.foundation.layout.fillMaxSize
import androidx.compose.foundation.layout.offset
import androidx.compose.foundation.layout.size
import androidx.compose.material3.Button
import androidx.compose.material3.Text
import androidx.compose.runtime.Composable
import androidx.compose.runtime.getValue
import androidx.compose.runtime.mutableStateOf
import androidx.compose.runtime.remember
import androidx.compose.runtime.setValue
import androidx.compose.ui.Alignment
import androidx.compose.ui.Modifier
import androidx.compose.ui.geometry.Offset
import androidx.compose.ui.graphics.Color
import androidx.compose.ui.unit.dp
import androidx.compose.ui.unit.round
import androidx.compose.ui.viewinterop.AndroidView

@Composable
fun DraggableDemo(modifier: Modifier = Modifier) {
    Column(modifier.fillMaxSize()) {
        var offset by remember { mutableStateOf(Offset.Zero) }

        Box(
            Modifier.offset { offset.round() }
                .draggable2D(rememberDraggable2DState { offset += it })
                .size(200.dp)
                .border(1.dp, Color.Red),
            contentAlignment = Alignment.Center,
        ) {
            Column {
                Button(onClick = {}) { Text("Compose button") }
                AndroidView(factory = { Button(it).apply { text = "View button" } })
            }
        }
    }
}

For this issue specifically, all AndroidViews inside Compose are treated defensively as if they might scroll, so ripples will always be delayed (even if there is nothing scrollable in the hierarchy). In the future when we have public API we would implement this to follow the same logic used within compose.

For the compose case, we only apply this logic to scrollable() and other scrolling containers, not to draggable. If the 'issue' here is that you want the compose case to not instantly show a ripple, as a workaround if you add an empty scrollable with zero size somewhere in the hierarchy above the rippling component, it might work.

Note that this work is tracked in our backlog, but not being actively worked on / won't be for a minimum of a few months.

For the compose case, we only apply this logic to scrollable() and other scrolling containers, not to draggable

Any chance we can have an early experimental version of a public API to be able to do the same in our custom pointer inputs/draggables?

Current update:

There are some similar issues in the same problem space that we aim to solve together, rather than trying to patch over these issues with different hard-to-maintain APIs. Basically there's a general issue here of gesture coordination, where high level gestures (e.g 'drag') need some level of coordination between each other. This is true for this case, cases like handling touch slop for multiple lazy lists, etc.

The current loose idea is building some higher level abstraction around gestures, built on top of pointerInput. E.g you could imagine some Modifier.gesture() API, that allows for some higher level logic, and communication between gestures in a hierarchy. As mentioned previously this is on our backlog, and this should solve this specific bug too when we get around to implementing it