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
Currently, every call to View::update updates the model and then may, or may not, write output to stdout (or wherever) depending on rate limiting.
It might be good to instead have a thread dedicated to pushing updates:
The application thread that provided the update can return to its own real work faster, without potentially blocking writing to a slow terminal. (However, since updates are rate-limited, these writes should happen rarely and might not have much of an effect? Or they might?)
If a progress bar update happens within the cooldown from the last update, it has missed its chance to be painted: the progress bar will not repaint until there's another model update. Similarly, after a message is written the progress bar will not repaint until there's a new model update. This isn't a problem for applications that issue many updates, but for those that update sporadically it can be strange: the bar doesn't show the thing that's actually causing a long pause. Asynchronous repainting would let the bar paint every n milliseconds with whatever is the most current state.
I'm not sure if messages should also be painted by an asynchronous thread, presumably with some queue in between.
The text was updated successfully, but these errors were encountered:
Currently, every call to
View::update
updates the model and then may, or may not, write output to stdout (or wherever) depending on rate limiting.It might be good to instead have a thread dedicated to pushing updates:
I'm not sure if messages should also be painted by an asynchronous thread, presumably with some queue in between.
The text was updated successfully, but these errors were encountered: