Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New Cargo progress bar jittery in Emacs terms #6574

Closed
andrewbanchich opened this issue Jan 21, 2019 · 1 comment · Fixed by #6615
Closed

New Cargo progress bar jittery in Emacs terms #6574

andrewbanchich opened this issue Jan 21, 2019 · 1 comment · Fixed by #6615
Labels
C-bug Category: bug

Comments

@andrewbanchich
Copy link

If I run cargo run in any Emacs terms like ansi-term or term, it will always display the progress bar and won't animate correctly. See here for a screen recording comparing it to other progress bars working fine in Emacs as well as to itself working fine in my regular terminal: https://youtu.be/AJjVSsu5RSI

It also seems like it takes time to run again in Emacs and always shows the progress bar, even after not changing any code. In the normal, non-Emacs terminal if I don't change any code it seems to just run immediately without showing the bar at all.

Output of cargo version: cargo 1.32.0 (8610973 2019-01-02)

@andrewbanchich andrewbanchich added the C-bug Category: bug label Jan 21, 2019
@alexcrichton
Copy link
Member

Thanks for this! I think that this is related to the large number of draws that are being done, and I've noticed this on my Windows machine as well where the terminal is quite slow. Most of the time the progress bars are throttled in updates to ensure we don't overload the terminal, but in this case I think we unconditionally update the progress bar to have the most accurate information.

@kennytm or @ehuss would y'all be willing to look into this? I think there's two things we could tackle here:

  • One is that I think we clear current progress from the terminal a bit too aggressively. I think we pessimistically do it in some cases where we could print other information, but it ends up not being necessary in many cases. (this causes some flickering I believe)
  • The second is that we're unconditionally updating the terminal whenever a crate completes, but all "fresh" crates finish in the first half second which causes a huge number of draws. I think we'll want to throttle this somehow and live with a terminal that may be wrong for 100-200ms

bors added a commit that referenced this issue Feb 1, 2019
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
@bors bors closed this as completed in #6615 Feb 1, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants