Fast message insertions or updates cause weird UI and too many view renders

[lissine0]

Hi, thank you for this library.
I'd like to report an issue that happens when rapidly inserting messages.

This can be demonstrated by changing the timer interval in the ChatExample app from 2 seconds to less than 80ms.

Minimal diff

diff --git a/ChatExample/ChatExample/Screens/ChatExampleViewModel.swift b/ChatExample/ChatExample/Screens/ChatExampleViewModel.swift
index 405e3fa..0e5d737 100644
--- a/ChatExample/ChatExample/Screens/ChatExampleViewModel.swift
+++ b/ChatExample/ChatExample/Screens/ChatExampleViewModel.swift
@@ -56,7 +56,7 @@ final class ChatExampleViewModel: ObservableObject, ReactionDelegate {
     }
 
     func connect() {
-        timer = Timer.scheduledTimer(withTimeInterval: 2.0, repeats: true) { timer in
+        timer = Timer.scheduledTimer(withTimeInterval: 0.01, repeats: true) { timer in
             Task {
                 await self.interactor.timerTick()
                 await self.updateMessages()

ChatExample_demo.mp4

As you can see, the new messages appear, disappear, then reappear.
Since it's not easy to follow what's happening in a group chat with Lorem Ipsum messages, I set up a bot that sends me 100 messages, numbered from 1 to 100. Make sure to lower the playback speed to see it better:

100_messages_from_bot.mp4

I profiled this bot example using Xcode instruments. And it turns out that when rapidly inserting 100 messages, MessageView is rendered 5095 times.
In fact, the huge number of view renders makes the rendering finish long after the last message was received by the app.

On the other hand, inserting 100 messages slowly results in only 656 MessageView renders.

When does this happen in practice?

When would one receive messages very fast? There at least a couple of scenarios:

• Opening a busy group chat, after staying offline for a while
• Having a bot that frequently updates its message while generating it (Issues when last message is continuously appended and grows larger than screen #169)

Issue #169 is in fact the same as this bug, but triggered with fast message updates rather than insertions. This can be confirmed by watching the video provided there in very slow motion. We see a familiar behavior:

169_in_slow_motion.mp4

[f3dm76]

Hey @lissine0, tried setting it to 0.08 on latest version, looks good. The second video looks like text updates are coming in an incorrect order - like some previous updates go after later ones. That and the 0.08 problem could be an issue with queueing the lib had on that version. If it is, it should be fixed in current version, could you please give it a go?

In general, debouncing actual visual updates might be a good idea. Such frequent updates could've looked normal for a simple text view or UITableView (still you'd have most likely optimized that in the end, for processor's sake), but since this is a UITableView wrapped swiftui cells, I don't think there is a way for the lib to really control when it renders and rerenders the cells - the only solid leverage we get is when to update messages array.

As for your cases:

Opening a busy group chat, after staying offline for a while

Group the updates and append to messages once. If you want messages to appear in batches, you can use new updateTransaction to queue the updates. Still if there are a lot of them, appending every single one separately would look hectic for the user I assume.

Having a bot that frequently updates its message while generating it

I actually encountered this case, and the problem is: if you append text little by little, it is relayouting itself constantly, changing the places where it decides to put a new line, so it jumps all over the place. Also having the height of the messages change constantly doesn't let the user to actually read what is being typed. So it's better to use a fixed cell with transparent text, and only change the text's color.

Have a great day!