SharedTransition default spring has subtle trailing time until completely finished

jasongitmail commented 4 days ago

Issue Description

When a SharedTransition exists on a page, the action bar becomes very slow, will fail to respond to user taps to "go back" until ~2 seconds after the navigation was started. It feels laggy/buggy for users. This is much slower than when a SharedTransition does not exist on the page.

In this video, I tap "go left" and "go right" and the back buttons as quickly as it will allow me. Left has a SharedTransition, Right has a regular page navigation.

(You can't see it in the video, but when on the left page, I'm tapping "back" multiple times and it is failing to navigate before eventually there is a successful navigation back. When I tap "back" on the right page, it works on the first attempt.)

https://github.com/NativeScript/NativeScript/assets/50032291/ffeeee48-1c86-49cb-9878-75c518967fce

      navigate({
        page: Left,
        transition: SharedTransition.custom(
          new PageTransition(300, 'linear'),
          {
            pageStart: {
              x: 0,
              y: 60,
            },
            pageEnd: {
              x: 0,
              y: 0,
            },
            pageReturn: {
              x: 0,
              y: 20, 
            },
          }
        ),
      });

Reproduction

Reproduction on StackBlitz:

Click "go left" in the action bar and then try to click "close" as quickly as you can. It will take a couple sections until it's responsive, and you will have many failed attempts tapping "close" until then. This feels slow/laggy/buggy for a user.
In contrast, click "go right" (which uses a regular page navigation without a Shared Transition) and click "close" as quickly as you can. It remains responsive as expected.

Versions:

    "@nativescript/core": "~8.7.0",
    "svelte-native": "~1.0.0"

Relevant log output (if applicable)

(no useful logs)

Environment

Sharing the environment from StackBlitz where the reproduction lives:

OS: Linux 5.0 undefined
CPU: (2) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
Shell: /bin/jsh
node: 18.20.3
npm: 10.2.3
nativescript: Not Found

# android
java: Not Found
ndk: Not Found
apis: Not Found
build_tools: Not Found
system_images: Not Found

# ios
xcode: Not Found
cocoapods: Not Found
python: 0.2.0
python3: 0.2.0
ruby: Not Found
platforms: Not Found

Dependencies

"dependencies": {
  "@nativescript/core": "~8.7.0",
  "svelte-native": "~1.0.0"
},
"devDependencies": {
  "@nativescript/preview-cli": "1.0.12",
  "@nativescript/stackblitz": "0.0.8",
  "@nativescript/tailwind": "^2.1.0",
  "@nativescript/types-minimal": "~8.7.0",
  "@nativescript/webpack": "~5.0.0",
  "svelte": "~4.2.0",
  "svelte-loader": "^3.2.0",
  "svelte-native-preprocessor": "^1.0.0",
  "svelte-preprocess": "^5.1.3",
  "tailwindcss": "~3.4.0",
  "typescript": "~5.4.0"
}

Please accept these terms

[X] I have searched the existing issues as well as StackOverflow and this has not been posted before
[X] This is a bug report
[X] I agree to follow this project's Code of Conduct

NathanWalker commented 3 days ago

Thank you for this report @jasongitmail it's the length of the spring (which calculates a duration based off default spring parameters) - the duration is often trailing until completey finished whereby the transition state is removed allowing the actionbar to be tappable. Possible we could adjust spring default to have quicker time trailing to avoid default case. Using manual duration should avoid (meaning it will override spring) and should end promptly at duration.

jasongitmail commented 3 days ago

Possible we could adjust spring default to have quicker time trailing to avoid default case.

@NathanWalker Ideally it'd be possible to get rid of the spring effect and use a custom curve like 'linear' instead.

NathanWalker commented 3 days ago

That makes sense, we could do that as a better starting default while still allowing a standard spring by enabling it with safe defaults and also custom parameters.

NativeScript / NativeScript