-
Notifications
You must be signed in to change notification settings - Fork 0
Open
Description
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.
Metadata
Metadata
Assignees
Labels
No labels