Holding key when typing input exhausts render time

[ordo-n]

Issue summary

Holding down the "a" key to input "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa".... gets progressively slow the longer you hold it down. This is compounded by the more colored text is displayed in the terminal. It slows down dramatically to the point of freezing. I have tested this on several systems fast and slow. The render time in the dev tools is where the lag occurred.

Expected behavior

It should not use so much render time simply to insert characters into the input or when removing characters.

Actual behavior

Very slow, very laggy, freezes

Steps to reproduce

Print colored text to the terminal, the more that's printed the worse it gets
Then hold down the "a" key to insert "aaaaaaaaaaaaaaaa".. into the input and then hold backspace to delete. Both insert and backspace lag.

Browser and OS

Edge, Chrome,

Additional notes

https://jsfiddle.net/p29yh7ja/

[jcubic]

Warning: This URL has been blocked by Bitly's systems as potentially harmful.

…

try this https://bit.ly/4e4zLlq select the desired compiler in the installer

-- Jakub T. Jankiewicz, Senior Front-End Developer https://jcubic.pl/me https://lips.js.org https://koduj.org

[ordo-n]

I am limiting with outputLimit: 750

But due to my use of color the lag becomes terrible as soon as it reaches that limit. (it's quite bad even on a expensive CPU)

The only way to be lag free is to use outputLimit: 200 (not enough for my use case) or remove color entirely.

Are there any ideas for reducing render time? should the input really re-render the whole terminal (doesn't that seem unnecessary?)

The only other thing that I can think to do is to print raw html with colored spans instead of using the inbuilt coloring (i.e [[;red;]text]

AI has suggested that I use requestAnimationFrame but that hasnt worked for me, in fact it makes the lag worse.

[ordo-n]

Before I go ahead and make changes, would using colored spans instead of the inbuilt coloring increase performance?

Many thanks

[ordo-n]

Using colored spans with raw:true instead of the inbuilt coloring works to reduce the lag quite alot!

[jcubic]

This is really weird, because command line is a different component (jQuery plugin), so what's on the terminal should not affect the interaction with the Command Line.

I need to investigate. Thanks for reporting.

[jcubic]

I did a quick check and what you have is the limitation of the Browser. There are simply way too many DOM nodes on the page. The insert of the character trigger reflow of the whole page. Check this code that use { raw: true } and inserts single and double span

https://codepen.io/jcubic/pen/JjQmqQM

I'm not sure if I can do something about this to not break the library. But maybe something you can do to limit the reflow of the whole page. The performance Tool in Google Chrome says that this a bottleneck even with a single span.

[jcubic]

contain CSS property didn't help. I think that I will need to close this bug. The only thing I can think of that will improve performance is to use Virtual Output. Technique used by React-Window, but this will be a big task to create a feature like this. And this would be tracked as a separate feature. Maybe even for version 3.0 if it will ever happen.

Unless you have other idea how to improve performance.

[ordo-n]

I do not know the code base well enough to be of as much use as I could be but I think that the command input should be independent of the terminal, it shouldn't be so dependant on the rest of the terminal. If it were decoupled the performance would not matter as the input would perform well regardless of how many lines are in the terminal

[jcubic]

Before the virtual window is implemented, you can try using outputLimit: 0 option. It will only display as many lines as there are on the screen, no scrollbar.

[jcubic]

I found the root cause of this delay, when I commented one line the freeze is gone, but that line is there for a reason. I need to investigate if I can somehow get rid of it and don't change the behavior of the library.

[jcubic]

The fix was simpler than I expected, the problem was that in one place I compared width and used the wrong element and the code trigger each time you press a key, and it should only trigger when the terminal width change. This caused a whole page Layout update that took 50ms when a lot of DOM was on the page, enough to freeze the inserting keys.

[jcubic]

The issue is fixed on a devel branch and will be included in next release.

[ordo-n]

Brilliant news! I'm eager to test the developer branch. I haven't built the project from scratch yet. I do npm install but then the expected function npm run build doesnt appear to exist. Advise please.

[jcubic]

The project use make not npm to build files, but you don't need to build anything. Just clone the repo and change the branch, build files are part of the repo. If you use CDN for your project you don't even need to clone the repo. You can just grab files directly from github

<script src="https://cdn.jsdelivr.net/gh/jcubic/jquery.terminal@devel/js/jquery.terminal.js"></script>

You can also just download the file from github:

https://github.com/jcubic/jquery.terminal/blob/devel/js/jquery.terminal.min.js

[ordo-n]

can confirm it works perfectly