Improve progress bar flickering. #6615
Conversation
|
r? @nrc (rust_highfive has picked a reviewer for you, use r? to override) |
There was a problem hiding this comment.
This looks great to me, thanks! All those strategies sound spot on to me, and the code all looks great.
The only thing I'd wonder is if we could improve the situation with removing the need for self.progress.clear(). I think we basically funnel all output through config.shell(), so I wonder if we could add hooks there to clear progress and such? It'd be great if we could do something like register a current progress bar and then any prints would automatically clear the progress bar, and then the progress bar would auto-update next time it gets an update or something like that.
I suspect though that the form of auto-clearning like would be nice is actually pretty difficult to implement and not easy to set up. Perhaps worth giving it a small stab though? If it doesn't work out I'm fine with manual clearning and vigilant reviews
| cx.bcx | ||
| .config | ||
| .shell() | ||
| .verbose(|c| c.status("Running", &cmd))?; |
There was a problem hiding this comment.
Since the verbosity check is already happening above, could this c.status(...) move into the if above?
ehuss
force-pushed
the
progress-updates
branch
from
0932af1
to
2932713
Compare
|
I've updated with a flag in The only other approach I can think of is to merge |
|
@bors: r+ Ok I think I'm personally a bit more in favor of this current flag, so let's stick with that and see how it goes! |
|
📌 Commit 2932713 has been approved by |
Improve progress bar flickering. This attempts to reduce the amount of flickering primarily by reducing the number of times the progress bar is updated. The outline of changes: - Don't display the progress bar for all the initial "Fresh" messages (if -v is not given). - Don't redisplay the progress bar if it hasn't changed. - Don't clear the progress bar if it is not displayed. - Don't clear the progress bar for `Message` events that don't print anything. - Drain messages in batches to avoid frequently updating the progress bar. - Only display progress bar if the queue is blocked. This significantly improves the initial "fresh" updates, but I still see some flickering during normal updates. I wasn't able to figure out why. Logging to a file and doing screen captures I see cargo is printing the progress bar <1ms after it is cleared. I'm guessing that it's just bad timing where the terminal renders just before the progress bar is displayed, and it has to wait an entire rendering cycle until it gets displayed. I tested on a variety of different terminals and OS's, but the more testing this can get the better. This unfortunately adds some brittleness of carefully clearing the progress bar before printing new messages. I don't really see an easy way to make that better since there is such a wide variety of ways a `Message` can be printed. Fixes #6574
|
☀️ Test successful - checks-travis, status-appveyor |
Fix overlapping progress with stdout. Minor issue introduced in #6615. The progress bar was not being cleared for stdout output (because Shell only does stderr).
Update cargo 7 commits in 245818076052dd7178f5bb7585f5aec5b6c1e03e..4e74e2fc0908524d17735c768067117d3e84ee9c 2019-01-27 15:17:26 +0000 to 2019-02-02 17:48:44 +0000 - Fix overlapping progress with stdout. (rust-lang/cargo#6618) - Improve progress bar flickering. (rust-lang/cargo#6615) - Add detail to multiple rename deps (rust-lang/cargo#6603) - Fix race condition in local registry crate unpacking (rust-lang/cargo#6591) - Revert "Make incremental compilation the default for all profiles." (rust-lang/cargo#6610) - Fixup the docs on crate-type (rust-lang/cargo#6606) - Document that owner --add now just invites (rust-lang/cargo#6604)
This attempts to reduce the amount of flickering primarily by reducing the number of times the progress bar is updated. The outline of changes:
Messageevents that don't print anything.This significantly improves the initial "fresh" updates, but I still see some flickering during normal updates. I wasn't able to figure out why. Logging to a file and doing screen captures I see cargo is printing the progress bar <1ms after it is cleared. I'm guessing that it's just bad timing where the terminal renders just before the progress bar is displayed, and it has to wait an entire rendering cycle until it gets displayed.
I tested on a variety of different terminals and OS's, but the more testing this can get the better.
This unfortunately adds some brittleness of carefully clearing the progress bar before printing new messages. I don't really see an easy way to make that better since there is such a wide variety of ways a
Messagecan be printed.Fixes #6574