Laggy Janky scrolling on iOS 15.5 and stable 3.0.1

[TommasoFramba]

Details

Target Platform: iOS
Target OS version/browser: 15.5
Devices: iPhone 11 standard 60hz not promotion

Scrolling is janky and laggy on stable 3.0.1, latest master, updated Xcode, and iOS 15.5 and goes away when screen recording is turned on or landscape mode. It feels like it is running on debug mode or half the frames. Below is a video that shows the issue. If you exit to home screen and open app up again the scrolling also returns to smooth for a while. But exiting app completely and restarting has low framerate all throughout. App in video is on release mode.

On Android release the app is smooth as butter so this is an iOS issue and goes away with screen recording or landscape.

https://drive.google.com/file/d/1VLq-4vqUpaPDxRBgGPJMAZRCUw50YIUF/view?usp=sharing

The app is rather complex but nothing out of the ordinary so I cannot list a reproducible file. However this issue seems to be the same one as noted by people in these issue threads:

#31086

Logs

Flutter doctor shows no issues

Logs

<!-- Finally, paste the output of running `flutter doctor -v` here, with your device plugged in. -->
Running "flutter pub get" in flutter_tools...                       4.5s
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 3.0.1, on macOS 12.3.1 21E258 darwin-x64, locale
    en-ZM)
[✓] Android toolchain - develop for Android devices (Android SDK version
    32.1.0-rc1)
[✓] Xcode - develop for iOS and macOS
[✓] Chrome - develop for the web
[✓] Android Studio (version 2021.2)
[✓] Connected device (2 available)

• No issues found!

[danagbemava-nc]

Hi @privateRepoF, would it be possible to capture some timeline traces using the devtools or some metrics in Instruments that capture the behavior you're seeing and share them with us?

Can you also look at #96381 to see if it is similar to your issue?

I did attempt to repro with the sample in #31086 but I didn't notice anything out of the ordinary. The frame time in instruments was steady across my testing.

Can you also see if you can reproduce it with the sample in #31086 and share the metrics for that as well? You can take a look at the trace file below in Instruments.

Thank you

104376.trace.zip

[TommasoFramba]

#96381 is the exact same issue. I am on an iphone 11 with 60hz display and it seems to go down to 15fps in exactly the same situations that #96381 describes.

I have also added the following to my appdelegate.swift and updated my info.plist to include CADisableMinimumFrameDurationOnPhone to true. This does not fix the issue.

override func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {        
        if #available(iOS 15.0, *) {
            let displayLink = CADisplayLink(target: self, selector: #selector(step))
            displayLink.preferredFrameRateRange = CAFrameRateRange(minimum:80, maximum:120, preferred:120)
            displayLink.add(to: .current, forMode: .default)
                                                
        }
        
        GeneratedPluginRegistrant.register(with: self)
        return super.application(application, didFinishLaunchingWithOptions: launchOptions)
    }
    
    @objc func step(displaylink: CADisplayLink) {
        // Will be called once a frame has been built while matching desired frame rate
    }

[danagbemava-nc]

Hi @privateRepoF, thanks for taking a look at that issue.

It will be best for you to share your findings and any other information that you have in that issue so that the team can take a look.

Closing from here as duplicate.

Thank you

[TommasoFramba]

I can confirm issue persists on latest master. Once again on iPhone 11.

[TommasoFramba]

I can also additionally confirm that this issue persists in a basic list view from the default flutter project.

The same issue is exhibited when locking the screen and returning or pulling down to view options and returning to the app. Once the jank has started it continues to persist and goes away by going to the Home Screen and opening up the app again or by putting the phone in landscape and then back again in portrait.

Here is a link to a slow mo video: https://drive.google.com/file/d/1WqPZME08irkYMppZ7o_WxqU3kG3mdmfL/view?usp=sharing

At 45 seconds you can see the significant change in frames per second after pulling down to view options.

Here is a link to a normal speed video: https://drive.google.com/file/d/1WpKCz0GZ66aUU3jAuLmYrl0HyyMZB0Js/view?usp=sharing

I'll update with dev tools screenshot but for now this clearly shows the issue exists on both master and stable.

import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  // This widget is the root of your application.
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        // This is the theme of your application.
        //
        // Try running your application with "flutter run". You'll see the
        // application has a blue toolbar. Then, without quitting the app, try
        // changing the primarySwatch below to Colors.green and then invoke
        // "hot reload" (press "r" in the console where you ran "flutter run",
        // or simply save your changes to "hot reload" in a Flutter IDE).
        // Notice that the counter didn't reset back to zero; the application
        // is not restarted.
        primarySwatch: Colors.blue,
      ),
      home: const MyHomePage(title: 'Flutter Demo Home Page'),
    );
  }
}

class MyHomePage extends StatefulWidget {
  const MyHomePage({super.key, required this.title});

  // This widget is the home page of your application. It is stateful, meaning
  // that it has a State object (defined below) that contains fields that affect
  // how it looks.

  // This class is the configuration for the state. It holds the values (in this
  // case the title) provided by the parent (in this case the App widget) and
  // used by the build method of the State. Fields in a Widget subclass are
  // always marked "final".

  final String title;

  @override
  State<MyHomePage> createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  int _counter = 0;

  void _incrementCounter() {
    setState(() {
      // This call to setState tells the Flutter framework that something has
      // changed in this State, which causes it to rerun the build method below
      // so that the display can reflect the updated values. If we changed
      // _counter without calling setState(), then the build method would not be
      // called again, and so nothing would appear to happen.
      _counter++;
    });
  }

  @override
  Widget build(BuildContext context) {
    // This method is rerun every time setState is called, for instance as done
    // by the _incrementCounter method above.
    //
    // The Flutter framework has been optimized to make rerunning build methods
    // fast, so that you can just rebuild anything that needs updating rather
    // than having to individually change instances of widgets.
    return Scaffold(
      appBar: AppBar(
        // Here we take the value from the MyHomePage object that was created by
        // the App.build method, and use it to set our appbar title.
        title: Text(widget.title),
      ),
      body: ListView.builder(itemCount: 100, itemBuilder: (BuildContext context, int index){
        return ListTile(
          leading: Icon(Icons.car_crash),
          trailing: Text("somebody look at this man"),
          title: Text("POS"),
        );
      }),
      floatingActionButton: FloatingActionButton(
        onPressed: _incrementCounter,
        tooltip: 'Increment',
        child: const Icon(Icons.add),
      ), // This trailing comma makes auto-formatting nicer for build methods.
    );
  }
}

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.