Layouting large amount of rich text is slow

[SirVer]

The chat window in multiplayer should only remember ~20 messages. Otherwise, there is always a notable lag when opening the window after some playtime when a lot of chatting was going on. This is because the whole textarea needs to be rerendered and relayouted each time.

The original name of this bug was:
Chat window remembers all messages ever

because the problem is most obvious with many chat messages in a game

[Nasenbaer (nasenbaer)]

sound useful - BUT:
There should be a function to view the chat history - perhaps steping back in 20 message steps or so.

[Nicolai Hähnle (nha)]

The obvious solution is to make the textarea implementation smarter so that it doesn't relayout everything all the time. Then there'd be no need to make the UI more complicated.

[Timowi (timo-wingender)]

The font/text rendering still needs to be reworked for opengl. I "fixed" this by disabling parts of the code. So it's the right time to put up some ideas how to do the text(/font) rendering.

[Nicolai Hähnle (nha)]

I think this particular issue is orthogonal to how font rendering is done. If I recall correctly the Multiline_Textarea tries to render the entire text at once, and this is what's causing the slowdown. If we instead did line breaks manually and rendered the text line by line, the problem would go away.

[SirVer (sirver)]

iirc the layouted text is cached as a SDL surface, but since the text changes with each message, it is relayouted each time.

While we are talking about the text rendering: other projects (like wesnoth) uses pango to layout text. It enables very rich text, including floating images and html like links. Moving to this or a similar library would greatly enhance our flexibility and would make a help system much richer and more pleasant to use.

[Nicolai Hähnle (nha)]

I suppose we should consider this fixed after bzr6501. Please reopen if you think otherwise.

[SirVer (sirver)]

It isn't. The new and the old rendering engine exist in parallel at this point in time. Rich text rendering still uses the old engine (there is a massive workload involved in converting stuff in txt/* into the new syntax, especially the license). I have shied away from doing this work and so far there has always been 'something more important',

[SirVer (sirver)]

Ohh.. help is appreciated of course :). Just remove usage of g_fh through g_fh1.

[SirVer (sirver)]

Charlie, if you want to work on this it World be usefull add raw text support to the new text rendering engine. Than the old one can be killed completely.

[SirVer (sirver)]

sorry for the last post - was made from my phone including the usual spelling errors :).

It would be really nice to get rid of the old font handling stuff - there is more to be done here (e.g. replace the current rich text rendering in campaigns with the new system), but the most difficult and the most crucial to get feature parity with the existing system would be to get raw string support. That is text that does not support formatting, but might contain a cursor (for editboxes and multiline editboxes). It would be terrific if you could work on this.

[SirVer (sirver)]

Setting to incomplete for bug sweeping.

[SirVer (sirver)]

Gun, could you summarize what the current situation here is? What still needs doing before b19?

[GunChleoc (gunchleoc)]

I am not planning to do the actual richtext multiline-textareas for Build19. There are still too many problems with fh1, e.g. images not being shown in messages.

So, I am doing the switchover element by element, e.g. buttons and tables are already done.

If you would like to work on fixing the problems, I should do a merge first.

[GunChleoc (gunchleoc)]

The old renderer is gone now, so I'm marking this as Fix Committed.

[GunChleoc (gunchleoc)]

Fixed in build20-rc1