Poor performance when subscribing to MouseRegion events

[LehaIvanov]

Hello,

Currently we developing a Flutter Web application with the intent to move to production in a few months. Almost everything works great but we found a major performance issue when subscribing to mouse events for many widgets.

We use ListView to display/scroll grid-like data and scrolling performance is 60fps on our testing devices which is perfect for us. But when we attach mouse event listeners to our widgets/cells we get major performance regression. (we tried to show tooltips using Tooltip widget but the problem seems to be much wider).

We found that this issue somewhat relates to widgets having rounded borders and/or different borders specified for each side. The problem should be easily reproducible so we provide only minimal main.dart examples without videos.

Scrolling in both examples below produces less than 60fps, but if you comment onEnter: (_) => {} handler in MouseRegion performance will increase dramatically and will reach 60fps.

main.dart: Case 1: Border radius

import 'package:flutter/material.dart';

Future<void> main() async {
  runApp(MyApp());
}

@immutable
class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    const int rowsCount = 60;
    const int columnsCount = 20;
    const double containerSize = 40;

    return MaterialApp(
      home: Scaffold(
          body: ListView.builder(
        itemCount: rowsCount,
        cacheExtent: rowsCount * containerSize,
        itemBuilder: (BuildContext context, _) => Row(
          children: List<Widget>.generate(
            columnsCount,
            (_) => MouseRegion(
              // Comment the line below to fix the performance problem
              onEnter: (_) => {},
              child: Container(
                decoration: BoxDecoration(
                  borderRadius: BorderRadius.circular(10),
                  border: Border.all(
                    width: 1,
                    color: Colors.lightBlue,
                  ),
                ),
                width: containerSize,
                height: containerSize,
              ),
            ),
          ),
        ),
      )),
    );
  }
}

main.dart: Case 1: Different side borders

import 'package:flutter/material.dart';

Future<void> main() async {
  runApp(MyApp());
}

@immutable
class MyApp extends StatelessWidget {
  Border _getBorder(int columnIndex, int rowIndex) {
    const BorderSide defaultBorderSide = BorderSide();

    return Border(
      left: columnIndex == 0 ? defaultBorderSide : BorderSide.none,
      top: rowIndex == 0 ? defaultBorderSide : BorderSide.none,
      right: defaultBorderSide,
      bottom: defaultBorderSide,
    );
  }

  @override
  Widget build(BuildContext context) {
    const int rowsCount = 60;
    const int columnsCount = 20;
    const double containerSize = 50;

    return MaterialApp(
      home: Scaffold(
          body: ListView.builder(
        itemCount: rowsCount,
        cacheExtent: rowsCount * containerSize,
        itemBuilder: (BuildContext context, int rowIndex) => Row(
          children: List<Widget>.generate(
            columnsCount,
            (int columnIndex) => MouseRegion(
              // Comment the line below to fix the performance problem
              onEnter: (_) => {},
              child: Container(
                decoration: BoxDecoration(
                  border: _getBorder(columnIndex, rowIndex),
                ),
                width: containerSize,
                height: containerSize,
              ),
            ),
          ),
        ),
      )),
    );
  }
}

We also found that the issue does not appear if we enable Skia based renderer so its source might be in Flutter Web engine, not in framework.

Please let me know if you need any additional information (videos, profile snapshot, etc) to diagnose the issue.

We wonder if there any existing issues/plans to improve Flutter Web performance in such scenarios, or is there any workaround for this?...

Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel unknown, v1.10.6-pre.7, on Microsoft Windows [Version 10.0.17134.950], locale ru-RU)

 

[√] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
[√] Chrome - develop for the web
[√] Visual Studio - develop for Windows (Visual Studio CommunityВ 2019 16.3.0)
[√] Android Studio (version 3.5)
[√] VS Code (version 1.38.1)
[√] Connected device (3 available)

 

• No issues found!

[jonahwilliams]

cc @ditman

[jonahwilliams]

cc @gspencergoog

[ditman]

Woah, I'll try to profile this to see where the time is going, since I recently tweaked some rendering of DRRects. Thanks for the repro code!

[gspencergoog]

The current implementation generates a new frame for every mouse move, but that would only produce a regression when the mouse is moving, not otherwise. There's a fix for that in #41014

[LehaIvanov]

@gspencergoog, today we just switched our Flutter installation to this commit in #41014 and the issue is still there, we didn't notice any improvements in our cases...

[gspencergoog]

OK, that's as I suspected. More likely it has to do with the rendering.

[ditman]

I did some profiling, and the issue seems to be related to a spike on DOM operations, and not necessarily to how we draw drrects into canvas (phew). I'll keep digging.

@LehaIvanov you call this a 'regression': has this ever worked well for you, and then it started being slow after some change, or is it just that performance gets worse when adding the onEnters?

[LehaIvanov]

@ditman thank you for your help with this issue.

I used "regression" term by mistake: this is not a regression - I had never seen this working well.
Actually, I mean "performance degradation" and yes - the performance just gets worse when we add mouse events.

We also did some investigations and we almost pretty sure that this issue not related to rounded rect painting: it seems to be related to engine/compositing code and/or DOM operations.

Please let me know if you need any further help with this. We plan to go to production with Flutter Web in a few months and this is currently the only blocker we have. So I will definitely do everything
that will help to land the fix sooner :)

[ditman]

@LehaIvanov So after a bunch of investigation, it seems that the issue is that active MouseRegions create additional PictureLayers that "break" the optimizations that the relayout boundaries of the Row widget provide (we end up with "too many layers", which in web translates to "too much DOM churn").

I have a pushed a fix to my flutter fork (which you can maybe try on your app?), but I need to seek approval from the owners of the MouseRegions feature (@gspencergoog ?), because I might be breaking something that I'm not even aware of.

Apologies for the delayed response, it took me a while to figure a root cause for this one :)

[jonahwilliams]

The MouseRegion creates AnnotatedRegion layers in the layer tree, which I assume are passed to the web engine as is? These don't have any effect on rendering, so it might be possible to filter these out, so to speak, when talking to the web engine

[LehaIvanov]

@ditman, thank you very much for your efforts working on this issue. Today we tested your fork with our cases and everything works great!

Actually, we are trying to render many elements on screen with tooltips. We found another performance issue (not related to this one) with tooltips / global routes. We plan to fill an issue and create a PR that fixes it ourselves in a few days.

So we are looking forward to see your changes in Flutter master soon :)

[ditman]

@LehaIvanov thanks, we're looking forward to see what you put in production, if it's publicly available!

@jonahwilliams I think that's more or less what I did. The "problem" seems to be that instead of having a tree like this:

Row
  PaintLayer

(Which is the case when the MouseRegion is not active) we end up with this:

Row
  MouseRegion
    PaintLayer
  MouseRegion
    PaintLayer
  ...

So the relayout boundary of the Row, which allows it to bunch a group of paints together into a larger PaintLayer is split into smaller ones (children of the MouseRegion), which in turn causes a very large number of DOM nodes to be created and moved around.

This is not a big problem in other platforms, where canvas allocation is not as bad (in fact the OP says that with the Skia backend, this is fine), but in normal web with canvas, touching the DOM this much is quite expensive and performance drops.

I didn't find a (fast) way to do post-processing here, since layer creation is somewhat tied to DOM nodes. We may be able to brainstorm some ideas for a more proper fix for this, rather than "don't break up the rendering when pushing layers that really don't paint anything", but that felt like a much larger scope (to the point that I'm not entirely sure how large it'd be :P)

[dkwingsmt]

I'd like explore the possibility of removing the need of annotated region layers and letting the parent layer or the layer tree take care of the annotation. However I'll have to do it after my current project (mouse cursor).

[ditman]

Thanks for taking this over @dkwingsmt!

I'm going to dis-assign myself, since I'm not going to work on this directly. Feel free to ping me if I can be of any assistance (I'll keep my branch up just for reference, at least for a while)!

[hossainiir]

Hi, is there any update for this issue?

[dkwingsmt]

@hossainiir I do have a plan for this and I’m working on it now. It is due to some design issues about hover detection and we want to fix it in the most elegant way.

[hossainiir]

@dkwingsmt Thanks, In my app I have about 100 controls that have MouseRegion, this issue causes my app to have lot lags.

[agyimr]

I also created a little pet project web application, deployed it and the performance is extremely slow... I mean I am unable to scroll the site on mobile.

I hope it gets fixed because I have great plans for flutter web :)

[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.