Open
Description
Describe the bug
The UI appear to be stuttering when there is a large enough data set being loaded into the UI. This is because the UI favours the use of columns over a more efficient ListView or builder widgets that renders on the fly.
To Reproduce
Steps to reproduce the behavior:
- Create a ChatView and inject large list of messages each time - either in the initiaMessageList or during loadMoreData
I've created a demo app to demonstrate this: https://github.com/lhengl/chatview_errors
- Tap ScrollController Error list tile
- Change the states to see the stutter
Expected behavior
There should be no stutter
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):
N/A
Smartphone (please complete the following information):
N/A
Additional context
N/A
Metadata
Metadata
Assignees
Labels
No labels
Activity
officialismailshah commentedon Jan 9, 2025
did you resolve this issue @lhengl
lhengl commentedon Jan 9, 2025
No, I haven't resolved this issue yet. Also, for some reason, I can't fork to attempt a fix... it just won't create a fork ok github for me.
officialismailshah commentedon Jan 11, 2025
sure here you can fork this repo I have forked it just now
https://github.com/officialismailshah/flutter_chatview
lhengl commentedon May 14, 2025
I'm trying to fix this issue because the stuttering is unbearable, so I had a look at this issue today and it's little bit confusing how this seem to work. It looks like the inner most ChatGroupedListWidget does use a ListView.builder(). However the parent widget wraps it inside a column, which in turn is wrapped by a SingleChildScrollView. This is an anti pattern, because I don't think that a SingleScrollView is meant to wrap a more efficient ListView.builder.
Until someone can confirm why this decision was made, I'm reluctant to make any changes because it might break something. But from what I can see moving it to a CustomScrollView with SliverList will likely make it much more efficient. Might have to lift the StreamBuilder higher up on the widget tree as well.
This is kind of a big change but a critical optimisation. Does anyone with a much more expertise on this package that can comment?
Here's the said code:
lhengl commentedon May 14, 2025
An update on this. After I changed the SingleChildScrollView to a CustomScrollView, I noticed a massive improvement in the speed and quality of the ChatView. For example loading hundreds and thousands of messages now are instant. Before it would have caused about a one second stutter delay. This is especially noticeable when opening the chat for the first time through routing, you'll see the animation of the routing is stuttering, indicating too much work is being done.
However, the logic in how the list is ordered is now incorrect. Before, the SingleChildScrollView's reverse property do not need to reverse the list in order to work because it laid out all its child view already. So the order of the list remain in tact. Now that we want to move to a build on the go list of sliver children, the ordering will need to be reversed in order to build the item one by one.
At the moment reversing the list seems to somewhat work, but:
I need help with this. Again, anyone with some expertise on the package can help would be great, because this is such a critical update to optimising the package. It's extremely inefficient to lay out the entire list in a single child scroll view.
Here's the forked branch for this: fix/ui-stutter
lhengl commentedon May 16, 2025
I've managed to fix the issues! I can now load hundreds and thousands of messages without any stuttering or memory inefficiency. I'm gonna play around with it a bit more to ensure it doesn't break anything. Feel free to test the fork here: fix/ui-stutter-caused-by-single-child-scrollview
lhengl commentedon May 30, 2025
Can someone from @SimformSolutionsPvtLtd please make a comment on their stance on this issue? I'd like to contribute to fixing this issue, but I'd really like your support because it will be a big change due to the fundamental change in how scrolling works.
I'd really like to optimise this package to support a more efficient scrolling logic. At the moment it is very inefficient use of a SingleScrollView that is pre-rendered from top to bottom, but the scrolling is reversed. Instead, this should be inside a CustomScrollView with the item built on demand in reversed order to align with the reversed scrolling.
@rishabhsimformsolutions, @Sahil-Simform?