Optional Rendering Trigger Mechanism

[jbwfu]

Is your feature request related to a problem? Please describe.

Currently, bubbletea program redraw at the frame rate by default. This can lead to unnecessary resource consumption in certain scenarios. For applications that primarily display static text or have infrequent UI changes, high-frequency redrawing is unnecessary and increases CPU and GPU load.

Describe the solution you'd like

1. Disable Automatic Redrawing: Offer an option (e.g., during Program initialization) to disable the default frame rate-based automatic redrawing.

2. Manual Redraw Triggering: Provide a method or mechanism for developers to manually trigger redrawing when needed. For example, this could be achieved by sending a specific Msg to the Update function or calling a designated method.

Describe alternatives you've considered

Consider providing an additional option that allows developers to choose a "redraw on write" mode. In this mode, any modification to the Model will immediately trigger a redraw. This can reduce the amount of code needed for manual redraw triggering.

Additional context

[meowgorithm]

Hi! The framerate-based nature of the renderer actually just limits the repaint frequency in order to reduce load, and repaints only occur when necessary. Message receives in Update are the only things that can trigger a repaint, and repaints only occur if View returns different output from the prior render. Here's how it works:

1. When the program is idle (i.e. there’s no I/O) no repaints occur
2. If Update is called (i.e. there's I/O) View is called after Update returns
3. If View returns the same value since the last render, nothing happens
4. If View returns a different value since the last render, the changed portions are redrawn
5. If Update and View are called in high succession, repaints only happen at most N times per second; this is where the framerate portion comes into play.

In other words, there are no repaints when the program is idle, only calls to Update can trigger repaints, repaints only occur when output from View changes, and repaints can only happen as often as the framerate allows.

I'm going to convert this to a discussion (for further discussion). If we find there is a feature here we can convert this back to an issue.

[jbwfu]

I'm a beginner in Go, and my understanding of the code may not be comprehensive enough. I apologize for not fully understanding how bubbletea's renderer works previously. Limiting the maximum refresh rate with a framerate is indeed reasonable. However, checking every frame might still have room for optimization in programs that are used for extended periods.

Here are the test results I obtained using Static Progress:

Expand/Collapse

I crudely disabled framerate support for comparison. Judging from the results of the time command (numerical comparison), the difference is significant.

For programs where the update frequency of the displayed content is determined to be low (its update frequency cannot reach the current framerate limit), disabling framerate support is reasonable.

This seemingly insignificant resource consumption might be negligible for a single program. However, for a Go library, I believe it's worthwhile to provide some degree of control over it.