TabView swipe animates too slow compared to Android

Use case

When you swipe through your tabs, it takes quite some time until the animation is finished. So you really have to wait until you can scroll down. It also slows down even more at the end of the animation. On native android apps this animation is way faster...

Proposal

Please make the animation similar to android.

Thanks in advance :)

@Hixie

I submitted a PR to fix this #95423

One thing I wanted to discuss with someone from the team - is the way we should treat the old implementation (which uses the ScrollPhyics.spring).

Some people are apparently using it to adjust their TabBarView/PageView physics in the way that is shown in this comment #55103 (comment), so just dismissing it entirely would ruin their implementations. On the other hand, most of the people are likely using it just to speed up the current default implementation, so it might be an unnoticeable change.

So, we can:

Support old spring simulation - if we detect that the spring is overridden
Do nothing, if one wants to use old implementation, they can copy old implementation into their code

In the PR I chose the approach №1 (just so we have an example to discuss upon) - but it seems a bit fragile, because uses identical, however accomplishes the purpose of not breaking people implementations.

/cc @Hixie @Piinks

@goderbauer

I agree with you that #1 is weird. #2 is sort of weird too, in that it means spring doesn't have an affect.
Is there a way to cleanly implement the new logic as a SpringDescription subclass?
Can we make ScrollPhysics.spring have some sort of supertype that covers both this behaviour and the regular behaviour?

cc @goderbauer also who may have opinions.

Is there a way to cleanly implement the new logic as a SpringDescription subclass?

I don't think there's a way. SpringDescription is meant to describe a spring by this model https://en.wikipedia.org/wiki/Mass-spring-damper_model. The new simulation logic basically has different solutions, and these solutions wouldn't map to any of 3 types of springs that this model has.

Can we make ScrollPhysics.spring have some sort of supertype that covers both this behaviour and the regular behaviour?

Can you elaborate?

in that it means spring doesn't have an affect.

This parameter in ScrollPhysics doesn't have a descriptive documentation as to where it's used, but PageScrollPhysics are the only place where the physics are entirely driven by it. In all other places it is only used to settle down when going out of range, i.e.

_SnappingScrollPhysics
FixedExtentScrollPhysics
BouncingScrollPhysics
ClampingScrollPhysics

Given that, it makes me wonder if that's actually a problem, in a way that it might be actually fixing an unwanted dependency on this parameter.

Can we make ScrollPhysics.spring have some sort of supertype that covers both this behaviour and the regular behaviour?

Can you elaborate?

When we have a situation like:

Class P provides feature X
  |
Class Q doesn't need feature X

...one solution is:

Class A (abstract)
  |     |
  |     +--------- Class P provides feature X
  |
Class Q

This parameter in ScrollPhysics doesn't have a descriptive documentation as to where it's used, but PageScrollPhysics are the only place where the physics are entirely driven by it. In all other places it is only used to settle down when going out of range, i.e. [...]

oh interesting, would PageScrollPhysics still use the spring for those other cases then?

oh interesting, would PageScrollPhysics still use the spring for those other cases then?

Well, it doesn't do that on its own, but it defers it the parent here, so practically yes.

It seems like we could discourage the driving usage (by adding docs), and declare that the previous PageScrollPhysics implementation was simply an oversight.

Can we make ScrollPhysics.spring have some sort of supertype that covers both this behaviour and the regular behaviour?

Can you describe what it would specifically look like? (It's hard for me to see from the abstraction you gave above, how to apply it to solve the problem)

oh interesting, would PageScrollPhysics still use the spring for those other cases then?

Well, it doesn't do that on its own, but it defers it the parent here, so practically yes.

It seems like we could discourage the driving usage (by adding docs), and declare that the previous PageScrollPhysics implementation was simply an oversight.

Yeah, that seems reasonable. If the property still has an effect, we document that that is its effect, and we don't worry about the way it doesn't affect the main driving case.

Can we make ScrollPhysics.spring have some sort of supertype that covers both this behaviour and the regular behaviour?

Can you describe what it would specifically look like? (It's hard for me to see from the abstraction you gave above, how to apply it to solve the problem)

I don't think this matters if we do as you describe above.

I'm not sure if it's possible to do what I describe in this concrete case, I was just suggesting a general approach that's worked in similar situations before but each case is unique and sometimes this approach doesn't work.

We are reverting the change that closed this, so I am re-opening the issue.

For what it's worth I spent a long time trying to tweak the spring on PageScrollPhysics to get this to work more smoothly on a PageView but in the end I found tweaking the controller to work much better:

class NowPlayingPageController extends PageController {
  NowPlayingPageController({int? initialPage})
      : super(initialPage: initialPage ?? 0);

  @override
  Future<void> animateToPage(
    int page, {
    required Duration duration,
    required Curve curve,
  }) {
    return super.animateToPage(
      page,
      duration: Durations.short4,
      curve: Curves.easeOut,
    );
  }
}

Navigation Menu

Repository navigation

TabView swipe animates too slow compared to Android #38357

Use case

Proposal

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

TabView swipe animates too slow compared to Android #38357

Description

Use case

Proposal

Activity

nt4f04uNd commented on Dec 16, 2021

Hixie commented on Dec 22, 2021

nt4f04uNd commented on Jan 3, 2022

Hixie commented on Jan 4, 2022

nt4f04uNd commented on Jan 4, 2022

Hixie commented on Jan 8, 2022

Piinks commented on Jan 24, 2022

milesegan commented on Sep 30, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions