Freezes in chat window

[Fohroer]

Expected behavior

Smooth message window without freezes.

Actual behavior

When there are about 40 lines of text Kontalk begins to lag. As I think it needs to use more more CPU power and more RAM in such situations but isn't asking of it from Android system.
And that's not all. After sending such message we'll still get such freezes when scrolling this chat to earlier messages. And freezes stops only when big amount of short messages fills the bottom of chat.

Steps to reproduce

1. Open chat
2. Write 40 lines of text
3. See the freezes

Environment

Kontalk version: F-Droid Stable

Android version: 4.4 and newer (maybe earlier too)

Device model: problem is not only on my device (Oukitel U7 PRO)

Other

What I call big message? About a half of book's chapter. Try this. Then re-paste it 5-6 times.

TesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttestTesttest

[CrimsonFork]

I don't know how it works but for me it seems like only visible messages are kept in their decrypted form in the RAM.

Also it seems like when writing a message it's being encrypted with every single change.

Maybe there should be options to adjust this.

[webratte]

Never before I sended a big message like this ;-)

But if I trie this also with Treema it's nearly the same. Threema works a lttle bit faster but stop scrolling for a moment if I reach the end or the top of the big message. And closing the App is also a little bit faster then closing Kontalk.

Maybe IMs not really made for big messages like this?
I don't know....

Sure, it seems there people aut there who do that.

[TheLastProject]

Telegram can deal with large messages without slowdown, so this is probably a bug. In my case I also noticed that if I type long messages in the message compose text field at a certain moment it starts to get slower and slower. It just never bothered me enough to report it earlier.

[CrimsonFork]

Maybe IMs not really made for big messages like this?
I don't know....

Well, if we start from that point, THE INTERNET itself wasn't made for big messages like this. Don't forget that the first message sent trough the internet was just 5 characters long and even that worked only after the second try. ;-)

[webratte]

Point gos to @OffifialMITX :-)

[Fohroer]

I think that nice solution to fix this is to encrypt message only before sending, not after entering new symbol.

[daniele-athome]

Thanks for reporting. This is partly due to how Emojicon renders emojis. The library scans for emojis at any view/modification in the whole text. For performance reasons, Kontalk disables this scan when text size reaches 10k (which is a lot). Apparently that's not enough, but I don't feel good either lowering that limit.

Emoji performance is a big deal and not easy to handle. #814 was opened to switch to another library, but I believe this has more to do with the approach used. Besides the issue of scanning the whole text everytime, there is also the issue with loading emojis from single files rather than using a single big image and use tiling (I believe this was the Telegram approach IIRC).

I'll keep this open to address the text-scanning issue (please note that emoji scanning is done even if no emoji is actually in the text). I didn't do any deep research yet, if someone has technical notes on this, please share them.

[Fohroer]

@daniele-athome I do believe that Kontalk must use a bit more RAM and CPU by default to have some kind of safe-zone.

[daniele-athome]

Memory usage is a very serious matter on Android. You can't really control how much memory is assigned to you and you can bump into the heap limit very easily. Besides, this has to do with the way Android recycles object (to conserve RAM).

[webratte]

I have just for fun tested it again with Threema. If I put the test text of @Buranek 3 times into the input field and add a Emoticon all is good. If I put the test text 4 times into the input field and add a Emoticon it will be not shown. They seems to stop earlier to scan for Emoticons then Kontalk.

@TheLastProject just for curiosity, what about Telegram?

[Fohroer]

@daniele-athome is it real to adapt code from Telegram client for emoticons? So good solution can be used.

[daniele-athome]

@daniele-athome is it real to adapt code from Telegram client for emoticons? So good solution can be used.

You didn't look at the Telegram source code. It's not very reusable. Most of the GUI is built directly from code, there are few to zero comments, the code seems like to have been generated or transformed by some program. I could get ideas from them (and I will look of course), but not code.

[CrimsonFork]

I've tried the suggestion of @Buranek without using encryption and the fun fact is that disabling encryption seems to speed everything up while writing BUT my phone almost crashed trying to render both messages (I've sent it to myself).

Maybe it would make everything better if there was a setting which renders emojis only when at least e.g. one second ticks away after the last (view) change? I don't think that the result would be too disappointing, most people I know prefer rather smooth graphics then good but slow graphics.

Additionally, why not letting 10 of the messages in both directions from current view being pre-rendered (only after the view itself was rendered)?

[daniele-athome]

Maybe it would make everything better if there was a setting which renders emojis only when at least e.g. one second ticks away after the last (view) change? I don't think that the result would be too disappointing, most people I know prefer rather smooth graphics then good but slow graphics.

I'm sorry but that would really suck :-)
I believe I might work something else out.

Additionally, why not letting 10 of the messages in both directions from current view being pre-rendered (only after the view itself was rendered)?

Because of how Android ListView works, it's impossible to achieve that unless I write a new implementation of ListView (read: no 😉)

[daniele-athome]

Here was the culrpit:
rockerhieu/emojicon#116

Huge performance improvement. It will be in next beta.

[daniele-athome]

I talked too early. Now there is another bug with emojis... I'll check with upstream...

[daniele-athome]

Ok all fixed.

[Fohroer]

So what kind of bugs should we expect in beta?

[daniele-athome]

For this problem, no bugs I hope. There are still a couple of issues with group chats, pending feedback from the OPs. Take a look here (this is a set of all issues that should be fixed before releasing final 4.0): https://github.com/kontalk/androidclient/milestone/28