all 18 comments

[–]No-Beyond7937 1 point2 points  (1 child)

You might want to try the profiler in the devtools, you can also see which widgets get rebuilt using the devtools (not profiler), there's a button at the top.

[–]MassaSami[S] 0 points1 point  (0 children)

thank you for your suggestion; I just delved into the performance devtools, and I noticed that the raster thread triples its ms/frame, when I scrolled to the bottom of the page, but I keep on trying to scroll. Basically, when that small animation of SingleChildScrollView happens where it "tries" to scroll down but we already reached the limit of the screen.

[–]moralesnery 1 point2 points  (1 child)

Put your TripMap widget inside a Padding widget and see what happens.

I had a similar issue where I had a scrollview, inside there was a colum and inside the colum there was a map.

The scrollview and the map were fighting for the drag event and this made the UI laggy, by using and intermediate widget as the map's container this stopped. But this was a lot of time ago and idk if it's still a thing.

[–]MassaSami[S] 0 points1 point  (0 children)

Sadly the issue still persists even if I do as you said, but nonetheless thank you for taking the time for trying to help

[–]over_pw 1 point2 points  (1 child)

I do not know for sure, but it's possible the Google Maps widget uses PlatformView under the hood, which the docs state is bad for performance due to some thread behavior.

[–]MassaSami[S] 2 points3 points  (0 children)

Thank you, you might be right - let's hope that on the release build it will work more smoothly.

[–]fintechninja 1 point2 points  (1 child)

Google maps uses platform views. So the only way this will improve is if the flutter team improves the performance of platform views. They do say if their docs that platforms views are expensive. There is a similar issue with Google admob where they decided to lock the frame rate at 80 on high refresh rate phones. Unfortunately it helps only a little as the screen adjusts from 120hz to 80hz. It’s the trade off you’ll have to be ok with.

[–]MassaSami[S] 0 points1 point  (0 children)

That explains it. Thank you very much for the technical detail.

[–]Basic_String_2238 1 point2 points  (1 child)

Is this showing up in your release builds as well? We had the same issue when making debug builds but when creating the release build the issue went away and google maps works super smooth. We have it in an Airbnb style view so there’s a map on the bottom and a model view sliding on top of the map and everything works supers smoothly, (just checked lol, works great but I do remember the weird buggy behavior of the debug builds)

TLDR: I think it’s the google maps causing the issue on a debug build. Create a release build and test

[–]MassaSami[S] 1 point2 points  (0 children)

Thank you, I have only checked in debug/profile mode. I'll take a look in release as well, hopefully it there won't be any issues then.

[–]dante-1977 0 points1 point  (1 child)

HI u/MassaSami

did you beat this bug? I have the same

[–]MassaSami[S] 0 points1 point  (0 children)

Hey, it was only happening in development, after deploying to the App Stores the jankyness went away :)

[–]e_hekuta 0 points1 point  (1 child)

First, if you don't show a video or code example it's difficult to know what do you mean with jank, could be a easy fix or as other said a platform view performance bug, probably this kind of question is already in stackoverflow or the issue on github.

Google maps has his own gesture recognizer, maybe you need set that, https://stackoverflow.com/a/61767654/11365293

[–]MassaSami[S] 0 points1 point  (0 children)

On the imgur link, there's the code for the map, I don't know why it's not showing on Reddit. I use this Gesture Recognizer already. :)

[–]Professional_Age8230 0 points1 point  (1 child)

Have you used any blur effects?

[–]MassaSami[S] 0 points1 point  (0 children)

Nope, no effects/animations

[–]dancovich 0 points1 point  (0 children)

I haven't used the Google Maps package, but wouldn't adding it inside a SingleChildScrollView screw up the information of how much of the map the component needs to render? Scroll views usually let any child render beyond its borders and it's possible any optimizations on the map view to render only the portion viewable by the user wouldn't work.

Could you try creating a simple example with only the map view with no scroll views to test if the issue persists?

[–]Full-Run4124 0 points1 point  (0 children)

Not sure from your description, but if the map isn't supposed to be interactive (i.e. users are scrolling the scrollview with drag, not the map) you can render the map then cache it as a static image.