Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Swapping operation seems to happen too 'close' to the scroll #468

Open
zzorba opened this issue Dec 3, 2021 · 2 comments
Open

Swapping operation seems to happen too 'close' to the scroll #468

zzorba opened this issue Dec 3, 2021 · 2 comments

Comments

@zzorba
Copy link

zzorba commented Dec 3, 2021

Thank you for this library, I spent yesterday diving deep into it and wanted to say how thankful I am for both this and spring-scrollview.

When trying to get smooth scrolling/swapping, I noticed that the 'break' points for when the swapping of a Group from one set of data to the next was happening at about 1 screen height before the 'next' group would appear on the screen.

const wrapperHeight = idx(() => this._size.height, 700);

inputs[currentGroupIndex].push(sumHeight - wrapperHeight);
inputs[currentGroupIndex].push(sumHeight + 0.1 - wrapperHeight);

With this default, I was noticing a fair amount of swapping/redrawing as it scrolled. This issue is slightly more prominent on android, but with fast momentum scrolling I was getting a great deal of clipping on both platforms.

I tried adjusting this slightly to be a calculation based on the number of groups / size of groups present, i.e. try to perform the swap at the halfway point between groups.

    const wrapperHeight = idx(() => this._size.height, 700);
    const totalGroupHeight = groupMinHeight * (groupCount / 2);
    const pageHeight = Math.max(totalGroupHeight, wrapperHeight);

And then pageHeight is used instead of wrapperHeight. With this config and about 12-20 groups + a groupMinHeight of height/2, I was seeing much smoother scrolling on both platforms. There still seems to be an issue where Android 'updates' while the Animated.View are offscreen don't actually update until it enters the screen when scrolling fast, but some indications say this is an android optimization of some sort that is hard to get around.

What do you think, did I misunderstand this code or is there a reason that the swapping was always happing so close to the scrolling.

@bolan9999
Copy link
Owner

groupCount?: number; The group count (not section) of the rendered content. default value is 4, set it larger, eg 6 or 8.
groupMinHeight?: number; The min group height of the rendered content. default value is screenHeight/3. can be screenHeight or more.

@zzorba
Copy link
Author

zzorba commented Dec 4, 2021

Yeah, I see how these both control the number of groups / size of the groups.

What struck me as odd though was that regardless of how many groups you have / how large the groups are, the 'animated position swap' always happens when it is 1 screen height away. I'm talking about the calculation within Group, when currentIndex moves from showing content index 0 to content index 1, and the Animated.View interpolates it into the next position.

As a concrete example, say I have 20 groups each of height/2 -- creating a content buffer of ~ 10 * height. Even in this situation, the 'animated swap' will happen when you are 90% of the way to the point where the next currentIndex grouping would need to be shown.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants