Address Redraw Performance Issues

[sirati]

some of what i am writing here is based on my assumptions on how this is implemented. this feature request is mostly a note to myself, i will investigate further and later fork and create a pull request.

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Many inputs e.g. keyboard strokes, mouse events within under one expected frame time cause the lib to refresh the screen one time each. these can create lag in some terminals to the extend of needing a couple seconds to catch up on unrealisticly high input loads e.g. smashing the keyboard on the text input field.

Describe the solution you'd like
mark dirty (as requiring an update), and have a threaded updater that checks within a frame time if we are dirty. only in that case emit a redrawing.
Drawback: we may incur input lag up to one frame as well as how precise sleeping, waiting is

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

1. As input output is blocking we cannot proactively skip some input and render on the next as we have no guarantee when this will be
2. if input output on all or some platforms allows timeouts, we can instead schedule the update in the main thread upon reaching that timeoujt
3. instead of emitting all redrawings to tty we could also draw to a buffer and after redrawing is complete only emit the differences to tty, however this does not fix that some redrawing procedures might be computationally expensive

Additional context
Add any other context or screenshots about the feature request here.
I plan to investigate further and implement the solution suggested here myself as well as add buffering as an optional feature (alternative 3). i also will investigate alternative 2 and may only fall back to threading only if the current tty does not support timeouts. I also do plan to make all these optional features and keep the default behaviour intact

[tig]

Many inputs e.g. keyboard strokes, mouse events within under one expected frame time cause the lib to refresh the screen one time each.

You are not wrong and I appreciate you raising this issue. There's no good reason why the library currently does this...it's a result of a lot of interactions where performance and avoiding unneeded painting has not been a focus.

In my opinion it has reached a point that is problematic. This is one of the reasons that I've been working hard on refactoring core View things in v2. For example, this PR is really all about addressing this:

#2606

We don't have good instrumentation or tests that prove/demonstrate how bad this issue is. The CharMap scenario works pretty good.... it's performance SUCKS because so much gets redrawn when only a small thing has changed.