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
@bjorn3 Thanks for reporting! I think @djc has lowered the tickrate to 20 per second in #4602... Would you mind testing a little bit on your side by editing that value to see how low we could go without making the animation super laggy?
Or, alternatively, maybe we can add an env var to tweak that value?
Or, alternatively, maybe we can add an env var to tweak that value?
Pff, let's not go there for this. Adding more configuration surface does not make things better in the grand scheme of things, it just requires users to build more expertise.
I'm admittedly not too familiar with the library we use for the progressbar.
Is there a way to stop it redrawing the whole line when only a part has changed?
Could the update itself be faster? I mean from the video it looks like it first clears the output then prints the new output. Could it just overwrite in a single pass? Or somehow reduce the delay between the two so it's unnoticeable?
@ChrisDenton Possibly .set_move_cursor() is here to help but since I don't have the environment to reproduce the issue, I'm not sure what will fix or mitigate this...
If I understand it correctly, the flickering is happening because the terminal emulator is too slow for our output mode. If you can reproduce it with Windows Terminal then maybe give it a try?
Even 20 updates per second seems like a lot for a meter with an ETA with a one-second resolution. Why does it need to update more than, say, two times per second? One minute of downloading produces 100-200kb per progress bar of data on stdout at 20 ticks per second...
I'm sorry if you get a second copy of this. I posted it with the wrong account the first time.
@DHowett This has previously been discussed in #4757 (comment) and it seems (according to those who reported) that the said tickrate change is not required to address the issue, so nothing has been modified in that respect since.
Yes, reducing the update rate would be a separate issue. This issue was caused by the time between clearing a line and drawing the new line, which should have been instantaneous but wasn't. Even if we only updated once a minute, there would still have been a flicker when it does update. However that should be fixed in the next release.
Activity
rami3l commentedon Mar 17, 2026
@bjorn3 Thanks for reporting! I think @djc has lowered the tickrate to 20 per second in #4602... Would you mind testing a little bit on your side by editing that value to see how low we could go without making the animation super laggy?
Or, alternatively, maybe we can add an env var to tweak that value?
djc commentedon Mar 17, 2026
Pff, let's not go there for this. Adding more configuration surface does not make things better in the grand scheme of things, it just requires users to build more expertise.
ehuss commentedon Mar 28, 2026
I'm experiencing significant flicker on Windows as well. This is with Windows Terminal using a build from latest main (0a96a33):
rustup-flicker.mp4
rami3l commentedon Mar 28, 2026
@ehuss What would be a better value in your opinion? Will 2 ticks per second as mentioned above suffice?
ChrisDenton commentedon Mar 29, 2026
I'm admittedly not too familiar with the library we use for the progressbar.
Is there a way to stop it redrawing the whole line when only a part has changed?
Could the update itself be faster? I mean from the video it looks like it first clears the output then prints the new output. Could it just overwrite in a single pass? Or somehow reduce the delay between the two so it's unnoticeable?
rami3l commentedon Mar 29, 2026
@ChrisDenton Possibly
.set_move_cursor()is here to help but since I don't have the environment to reproduce the issue, I'm not sure what will fix or mitigate this...If I understand it correctly, the flickering is happening because the terminal emulator is too slow for our output mode. If you can reproduce it with Windows Terminal then maybe give it a try?
ChrisDenton commentedon Mar 29, 2026
Using
set_move_cursordoes seem to help. I'll put up a PR and hopefully others can test it.DHowett commentedon Jul 20, 2026
Even 20 updates per second seems like a lot for a meter with an ETA with a one-second resolution. Why does it need to update more than, say, two times per second? One minute of downloading produces 100-200kb per progress bar of data on stdout at 20 ticks per second...
I'm sorry if you get a second copy of this. I posted it with the wrong account the first time.
rami3l commentedon Jul 20, 2026
@DHowett This has previously been discussed in #4757 (comment) and it seems (according to those who reported) that the said tickrate change is not required to address the issue, so nothing has been modified in that respect since.
ChrisDenton commentedon Jul 20, 2026
Yes, reducing the update rate would be a separate issue. This issue was caused by the time between clearing a line and drawing the new line, which should have been instantaneous but wasn't. Even if we only updated once a minute, there would still have been a flicker when it does update. However that should be fixed in the next release.