Replies: 1 comment 2 replies
-
Event might cause some state to be updated. FTXUI doesn't what users are doing when receiving events. So we draw a new frame after handling events. Please note that it is redrawn only after handling all the pending events. So even if you have 1000 pending events, the screen won't be drawn 1000 times, but only once. This means the drawing rate is "auto-adjusted" to match the performance of the terminal. If this is an issue to anyone, we could take the result of: It returns a boolean telling if the event was "handled". We could use it to redraw only when users have acknowledged they "handled" the event. Nevertheless, this would break users submitting events to trigger a new frame to be drawn. |
Beta Was this translation helpful? Give feedback.
-
Hi, I've made a simple example with one dynamic field:
When I move mouse to anywhere, the counter goes up so the screen is redrawn. My issue is the continuous mouse movement generates roughly 60% load of one CPU core. That is quite a lot. That does not happen with other TUI applications like
top
even on button presses.I assume this is caused by running fullscreen and actually redrawing the whole screen even though only a small portion of it changed, is that correct?
Is there any way how to fix this? Maybe somehow signal from a component that it does not need to be redrawn? E.g.
canvas
in my example never changes (if the layout did not change).Does anyone have any experience what will this do to
ssh
performance on slow connection?Thanks for help.
Beta Was this translation helpful? Give feedback.
All reactions