You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ratatui does double buffering to efficiently update the terminal by only writing out what changed between draw calls. However, the UI is always redrawn every tick, and Ratatui is an immediate-mode framework meaning that the entire UI must be rebuilt in memory. Most of the time there will be no or few changes, meaning most of the just-created widgets will not be used.
Taking inspiration from the paradigms used in tui-realm, only call Terminal::draw if an event causes a state update. The main loop and event processing may need refactoring to make this easy.
Additionally, gather some metrics to see how this affects performance:
Measure how long it takes to render per tick
Monitor CPU usage before/after the change
The text was updated successfully, but these errors were encountered:
You might be interested to see what we have cooking in the 0.26.0 release...
Specifically we now support rendering references to all our widgets (except barchart), and the tehnique may work for your app too. See ratatui/ratatui#833 for some info and ratatui/ratatui#836 for a demo. This also can work for mutable refs, but care should be taken to not do destructive things tot the state that would prevent things rendering well. https://github.com/ratatui-org/ratatui/pull/865/files
A new alpha should be out sometime today / tomorrow if you want to take a look.
Ratatui does double buffering to efficiently update the terminal by only writing out what changed between draw calls. However, the UI is always redrawn every tick, and Ratatui is an immediate-mode framework meaning that the entire UI must be rebuilt in memory. Most of the time there will be no or few changes, meaning most of the just-created widgets will not be used.
Taking inspiration from the paradigms used in tui-realm, only call
Terminal::draw
if an event causes a state update. The main loop and event processing may need refactoring to make this easy.Additionally, gather some metrics to see how this affects performance:
The text was updated successfully, but these errors were encountered: