CoolTerm slow after connection on Linux Mint

[brown_roy]

Hello,
Thanks for the amazing application - CoolTerm. I use it on all my computers. I am currently just confused about a small thing I have encountered however.

I am planning on work on a project on one of my personal machine so I just installed Linux Mint 22 on it and installed CoolTerm. My machine is Ryzen 3700X with RTX 2060 super graphics card. I have CoolTerm installed on another Linux Mint 21 machine with a very old Intel i5 and GT730 graphics card. CoolTerm runs super smooth on the Intel machine (except for the scrolling issue) but when I run it on the Ryzen machine, it gets super stutter-y after I connect to a Silab COM port. I can still talk to the COM port but I notice that typing and general responsiveness of animations is not as smooth on the Ryzen machine as it is on the Intel machine. The scrolling issue, where the scroll bar goes back to the top once the page is full, feels worse on the Ryzen machine due to this stutter.

I have tried swapping the USB ports, no change. I opened up a TCP server and client port and that does not show the stutter. It seems to be only related to the serial port.

Both the machines should have the dependencies setup similarly. I am not sure where the difference could be. Any help on where to look would be very helpful.
Thank you!

[roger]

Hi,

to avoid the issue with the scroll bar going back to the top, enable the "Avoid Plain Text Flicker" option in the Preferences.

Hopefully this will also address the issue of the reduced responsiveness. I would also recommend not making your receive buffer too large.

I hope this helps.

Roger

[brown_roy]

Thanks! The "Avoid plain text flicker" option definitely helps with the scroll! Still no luck with the stuttering though. The buffer size is set to the default 10000. Let me know if you have any other suggestions I could try out.
Thank you!

[roger]

Hmm, I can’t think of anything else right now.

[chr.wiese65]

Hello Roger,

I would also like to thank you for this really well designed terminal emulation, great work, you rarely see something so clear and powerful at the same time. But I have the same problem as brown_roy.

I primarily use CoolTerm to debug embedded hardware via serial interface. Now to my problem description: If CoolTerm receives text data continuously for a long time and displays it in its window, it becomes slower and slower over time, as the thread creator has already described, and after a while (circa 30 minutes) it stucks completeley. I use it under Linux Mint, the PC is Lenovo Thinkpad i5 with integrated GPU. When I look at the system load with "top", I notice that it is slowly increasing for CoolTerm over time. If it approaches 100%, the output initially becomes stuttering, a short time later it is unresponsive. After that, only aborting the task and restarting CoolTerm helps. The behavior is reproducible. Have I set something wrong? The buffer size is the 10000 bytes default, changing it does not have any effect…

Do you have any idea what it could be?

Best Regards, Christian Wiese

[chr.wiese65]

A small update: I just checked it on another PC, Ryzen 5-5600G, Linux Mint, same effect. But new insight, if the cpu load is rising, a click on the "Clear Data" button resets the situation to initial condition. But after, cpu load is rising again.

[roger]

Hi Christian,

can you perform the following experiment:?
- ensure the "Show Send/Receive Byte counts" and "Reset Statistics when port opens" options are turned ON in the connection settings, under "Miscellaneous".
- The next time CoolTerm becomes slow, close the connection (disconnect) and then clear the data.
- Re-open the connection (connect). The byte counts should be zero.
- Check what the byte counts are when CoolTerm starts becoming slow and the CPU load starts rising again.

I have a feeling this may be due to the amount of data held by the text display is getting too much when the "Avoid plain text flicker" option is turned on, because, even when the receive buffer size is small, received data keeps pouring into the text display directly when this option is turned on rather than going into the receive buffer first and then the display being updated by the buffer contents. When this option is enabled, there is no limit to how much data is added to the display. That is certainly something I need to improve. The experiment above will help confirm my suspicion.

Roger

[chr.wiese65]

Hi Roger,

many thanks for the quick response. I did the experiment you recommended: My feeling was, the program started to slow down and react less well at 75% CPU load (approx. 5 MByte of data transferred/displayed at 115200, 8N1).
It stucks completely at ca. 7,5 Mbyte with 100% CPU load. The scrolling text in the main window first stutters, then stops completely, but the counter in the footer continued to run smoothly.
Out of curiosity, I turned off "avoid plain text flicker" and the CPU load is then constant at around 20 to 25%, which is still a lot, but it doesn't increase, not even overnight. Working with "avoid plain text flicker" activated is much more pleasant though

Best Regards, Christian

[roger]

Hi Christian,

thanks for confirming my suspicion. It seems that more than a few MB of data is more than a text control in LINUX can handle.

"Avoid Plain Text Flicker" is unfortunately something that seems to be necessary on most Linux systems. CoolTerm has an internal receive buffer that holds all received data. Whenever there is an update (new received data arrives, the user switches the view mode, etc), the current display is refreshed with the contents of the receive buffer. I.e. the display is always a perfect visual representation of what is in the receive buffer. This ensures that the contents of the receive buffer are always drawn properly.
This works well across the different display and across platforms, except for the text display on Linux. For some reason, replacing the contents of a text box on Linux is done in two separate steps. Removing the old contents, and then adding the new contents. Unfortunately, Linux refreshes the display at both steps. So, when new data arrives, Linux clears the display briefly and the display scrolls all the way to the top, and then it puts the contents of the receive buffer into the text display and scrolls back to the bottom. This is what's causing the flicker. And I can't figure out a way to prevent that. So that's where the "Avoid Plain Text Flicker" option comes in. Instead of replacing the text in the text display, CoolTerm just adds newly received data at the bottom of the display. This works fine in most cases, but the text display contents are essentially de-coupled from the receive buffer. This can lead to issues where feature like ANSI text formatting doesn't work right when parts of a formatting sequence are received in separate chunks as the code that processes the text for formatting now only operates on the data that was received last instead of all of the data in the receive buffer.
The other problem is the that the amount of data in the text display just keeps growing, even if the data in the receive buffer is limited. This is the problem you are seeing. However, I think I have a solution that might work by removing some of the text at the top when new data is received, which hopefully won't result in the display scrolling to the top and make the "Avoid plain text flicker" useless.
Look out for an e-mail from me once I have something to test.

Roger

[brown_roy]

Thanks for your prompt responses Roger,

Not to derail the scrolling topic but I was just hoping to give you another data point for the Linux serial port issue causing stuttering on CoolTerm. I just noticed that on Linux, this stuttering only happens for devices connected as /dev/ttyUSB0 and not the devices identified as modems, i.e. /dev/ttyACM0. I have an ESP32 module that connects to the Linux system as /dev/ttyACM0 and coolterm works great when connected to that serial port. I tried the new image you sent out and CoolTerm feels noticeably smoother. Still causes a lot of stuttering on /dev/ttyUSB0 though. Not sure if that gives you any indication but just thought I'd provide an additional data point.
Thank you!!