IssueTracker

Project: platform/frameworks/support
Branch: androidx-main
Author: Louis Pullen-Freilich <lpf@google.com>
Link:      https://android-review.googlesource.com/3328184

Adds OverscrollEffect#withoutDrawing and OverscrollEffect#withoutEventHandling

Adds OverscrollEffect#withoutDrawing and OverscrollEffect#withoutEventHandling 
 
These APIs allow overscroll to have events dispatched to it by one component, and rendered in a separate component. 
 
Fixes: b/266550551 
Fixes: b/204650733 
Fixes: b/255554340 
Fixes: b/229537244 
Test: OverscrollTest 
Relnote: "Adds OverscrollEffect#withoutDrawing and OverscrollEffect#withoutEventHandling APIs - these APIs create a wrapped instance of the provided overscroll effect that doesn't draw / handle events respectively, which allows for rendering  overscroll in a separate component from the component that is dispatching events. For example, disabling drawing the overscroll inside a lazy list, and then drawing the overscroll separately on top / elsewhere." 
Change-Id: Idbb3d91546b49c1987a041f959bce4b2b09a9f61

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

• androidx.compose.foundation:foundation:1.8.0-alpha06
• androidx.compose.foundation:foundation-android:1.8.0-alpha06
• androidx.compose.foundation:foundation-jvmstubs:1.8.0-alpha06
• androidx.compose.foundation:foundation-linuxx64stubs:1.8.0-alpha06

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

• androidx.compose.foundation:foundation:1.4.0-alpha02

Hi, the feature is still in the LazyList internal APIs. I've marked the feature complete because we'll opening it up in Pager (which is the main use case for it) and we're studying the possibility of opening it up in LazyRow/Column (https://buganizer.corp.google.com/issues/258606058).

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.