IssueTracker

Running the code from the map_swipe branch - I'm seeing that MapActivity and MapWithDismissActivity are scrolling the map ok, but the SwipeToDismiss is not working (so that's different to the behaviour reported above). But I do see the reported behaviour in App itself, that within SwipeDismissableNavHost, that SwipeToDismissBox is always handling horizontal swipes, so probably the map does not receive those gestures. Not clear yet why this is, because Modifier.edgeSwipeToDismiss is working for other horizontally scrollable components.

Having looked into this in more detail, GoogleMap does not support nested scrolling, so it's not compatible with Modifier.edgeSwipeToDismiss. Instead, we've seen that adding an 'enabled' parameter to SwipeDismissableNavHost and setting enabled = !cameraPositionState.isMoving would allow panning horizontally and vertically in the map (and adding a button to dismiss the screen). NB caveat is that there's a bug where the initial swipe needs to be vertical to avoid the parent handling it - this affects other scroll types as well as the Wear SwipeToDismiss.

We will look at adding the enabled parameter to Wear Compose in the near future (after release of 1.0).

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

• androidx.wear.compose:compose-navigation:1.3.0-alpha02

I'm also interested in this feature. When will it be available on LazyRow/Column?

Looking for this feature in LazyColumn.

Any updates on this?

We are looking into creating custom prefetcher APIs to address this feature.

For my app, I have a list of xml lines that are heavily formatted and processed. I need to use a lazy listview with an item per line for it to render properly. However on slower devices it scrolls with hiccups because it doesn't prerender a few items in advance.

I am still a Compose newbie, but from what I understand it's not possible to do this in a non recomposing way: determine optimal linebreaking for xml formatting. So it recomposes a few times to determine optimal layout. A render ahead option would at least make this not visible.

+111111111111111111111

Writing "+1" is not helping to increase the priority for the request as we are currently collecting exact use cases for this api as mentioned in comment#16

For my app I had a list/grid of videos that needed to open/close websockets while I scroll. Without offscreen loading, the loading of videos was too slow. I tried to load items offscreen using firstItemIndex, but since my list was highly customizable (multiple columns, dynamic items count on screen) it was pretty terrible.

I am developing a continuous sliding interface for vertical galleries, and I hope to be able to render 2-4 pages off screen in advance, rather than having users slide to the next page and load it again

From what we hear so far most of the use cases can be solved by prefetching adjacent items. Prefetch is our mechanism of composing and measuring extra items when the main thread is idle. Right now we only prefetch one extra item in the direction of scroll and we are considering tweaking this logic to prefetch more items by default and also make this logic configurable. We already created a simple experimental api for users to try to play with changing the logic completely (https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/lazy/LazyListPrefetchStrategy.kt), but we are still working on making this api even easier to use. Basically what I mean is that the requested use case will be solvable by still only composing items which are needed as visible during the main measure pass, and then we scheduled prefetch for a few extra items on the sides. It will make sure such item are composed before users scroll to them, but it will not block the main thread improving the performance. After we support that the only reason to still use apis like beyondViewportPageCount from HorizontalPager is when you really need to compose the adjacent items together with the visible items because you want the whole Paget to set its height to the height of the larger page including those extra item. As otherwise the height will be only using the heights of the currently visible items and "jump" once you scroll to the new larger page. For that use case we introduced this api into Pager, but are not seeing good reasons to add it into lazy lists for now

Do you need it in order to improve the performance only?

For me, yes

Will it help if we instead make it easier to tweak when and what items are being prefetched?

Yes. It would be helpful if I can just set a prefetch = 5 parameter.

The important difference here is that prefetch is not blocking the main thread and is only trying to load next item when the main thread is free

For me, that is fine.