JetBrains/jediterm — pull request #101 by Plonk42 (2014-06-30 14:53:02+00:00)
Title: Display performances improvment

When displaying a large output, JediTerm consumes a lot of CPU cycles, because of 2 threads:
- AWT-EventQueue-0 : graphic thread
- Connector-Remote : back-end thread
The main concern is that we are refreshing the display each time the back-end notifies it, resulting in a very high frame rate throttling performances. It is very visible if the computer has some weak graphic capabilities.

This PR reintroduced the FPS timer, improved to trigger the redraw only if needed (ie. we received a back-end event since the last display). Doing that, we repaint only when needed, and never faster than `MAX_FPS`.

`repaint()` is overridden to set the `needRepaint` flag, that will trigger the display on the next timer cycle.
This give us the control over repaints triggered by the model **and** by Swing (especially scroll model update).

Tests were done by running `cat big_file`, where *big_file* is ~25MB (~400 000 lines).
Results on my laptop (4 cores, 8GB RAM, dedicated graphic card 2000M) :

- 2fb42274ac1df3ad2ebcbdc552d4005dae363891
- AWT-EventQueue-0 : ~80% CPU
- Connector-Remote : 100% CPU
- 16.607 s
- 73ea797cf23245e3e9b3fc4481cc76e167bc2e9b
- AWT-EventQueue-0 : ~10% CPU
- Connector-Remote : 100% CPU
- 4.229 s

On a low-end laptop, the gain is even more impressive, dropping from 4m38s to 12s (the window manager (Xorg) was literally flooded and stalled, consuming 100% CPU).

Now we can see that the back-end thread is consuming all the CPU; I did not find anything simple and worthwhile to do.
Cycles are spent creating new lines (400 000 to instantiate in a few seconds), deleting top ones, and writing chars. Avoiding massive `String` instantiations in `TerminalTextBuffer.writeBytes()` may help.
That will be for a next time... :)