Improve performance of the list of chat messages

[danxuliu]

Requires #1302

It seemed that this day was never going to come, but finally, here it is :-D
🎆 🎆 🎆 🎆 🎆 This pull request is ready for review!!! 🎆 🎆 🎆 🎆 🎆

Each time a new element or a group of elements is added to the document the browser needs to layout it (calculate its position and height), but if the elements use a static or relative positioning (they are part of the flow of the document) it needs to reflow the document too (layout other existing elements again that could be affected or affect the new elements).

When joining a room all the chat messages in the room were loaded and added one by one to the document. Each time a new message was added to the list all the other messages already in the list had to be layout again, and thus the document was reflown again and again each time with a higher number of elements.

Instead of adding each message on its own when several of them were received an initial improvement is to add them all at once. This way, instead of one reflow for each element only one reflow for the whole set is needed. However, this only helps up to some point; once the number of elements in the list is very high even a single reflow takes a lot of time, so not only the initial load, but also regular chat is sluggish.

The only way to improve the performance is thus limit the number of elements in the list. The virtual list does that while giving the user the impression that the list contains all the messages. How? By keeping in the document only the elements that are actually visible, removing those that are out of view, and updating them as needed when the user scrolls the list. For more information please refer to the documentation in the code itself ;-)

Of course, despite its benefits, this approach also comes with its own issues :-)

• As the elements in the virtual list are removed when they are no longer visible, the selected text in a message disappears when the message is scrolled out of view. It could be probably solved by not removing the elements during a scroll if they are selected, but for the time being it is a limitation of this new implementation; I will try to solve that later in a different pull request.
• Firefox has subpixel accuracy for the position and size of the elements, but surprisingly the scroll position is handled as an integer. Due to this it is not possible to keep exactly the same scroll position when elements are prepended to the list, and several prepends in a row (for example, when the list is reloaded) cause a wiggly effect and a small drift from the proper scroll position. Unfortunately I do not know how to solve that, although it is only a nuisance more than a problem.
• It happened to me that when scrolling the list by keeping a key pressed Chromium stopped sending scroll events... and then when key was released sent them all of a sudden. I would say that it was just a strange (and not reproducible) Chromium bug more than a problem with the virtual list itself.
• Scrolling while the list is being reloaded in the responsive view of Chromium shows the wrong elements. The problem seems to be that when the scroll even is handled calling scrollTop() returns the scroll position when the event was triggered instead of the current one (as done in the normal view of Chromium or in Firefox), so when the visible elements are updated the wrong ones end being shown. I do not know how that could be fixed, but it should not be a very big problem, as once the reload ends the scrolling shows the right elements, and again it actually looks like a bug in Chromium, and only in its responsive view.

I have developed and tested the virtual list with the desktop versions of Firefox and Chromium; tests with the mobile versions are appreciated ;-) (And by the way, adding so much code without unit, integration or acceptance tests make me dizzy :-P ).

How to test (setup):
To notice the performance improvement it is necessary to use a room with a large number of messages. A naive way to get a room with a large number of messages would be to modify the ChatController to include the following code before $creationDateTime = new \DateTime('now', new \DateTimeZone('UTC')); in sendMessage:

	$numberOfMessages = 10000;
	$baseTime = new \DateTime('now', new \DateTimeZone('UTC'));
	$baseTimeTimestamp = $baseTime->getTimestamp() - $numberOfMessages;
	$currentMessage = 1;
	for ($i=0; $i<$numberOfMessages; $i++) {

			$creationDateTime = new \DateTime();
			$creationDateTime->setTimestamp($baseTimeTimestamp + $i);

			try {
					$comment = $this->chatManager->sendMessage($room, $actorType, $actorId, (string)$currentMessage, $creationDateTime);
			} catch (MessageTooLongException $e) {
					return new DataResponse([], Http::STATUS_REQUEST_ENTITY_TOO_LARGE);
			} catch (\Exception $e) {
					return new DataResponse([], Http::STATUS_BAD_REQUEST);
			}
			$currentMessage++;
	}

With that code, whenever a new message is sent to the controller (simply typing in the UI, for example) 10000 extra messages would be added too to that room.

That code should be used only during the setup of the room; for the actual test of the virtual list it should be removed, as otherwise even with a virtual list sending a new message would take time.

How to test:

• Enter a room with a large number of messages
• Send new messages
• Resize the window
• Scroll the list

Result before this pull request:
Go for a walk while the messages are loaded when entering a room and hope that the browser has not crashed when you return; make some stretches whenever a new message is added or the window is resized; wait a little when scrolling the list

Result after this pull request:
Make some stretches while the messages are loaded when entering a room*; enjoy an immediate update whenever a new message is added, the window is resized or when scrolling the list

*When entering the room the browser becomes slightly unresponsive; this is mainly caused by the continuous load of messages by the model without any throttling, but this was not fixed because it will no longer happen once the messages are loaded on request in a later pull request.

[nickvergessen]

Works 🐘

[nickvergessen]

No backport on this one 🙊