Progress indiciator is redrawn too frequently

[dpc]

Description

Steps to Reproduce the Problem

Use jj over some slower ssh connection. Run jj git fetch, watch how the redrawing progress bar slows down the whole ssh connection.

Expected Behavior

Limit the redraw frequency to 1/s, maybe slightly more.

Actual Behavior

Lag.

Specifications

• Platform: NixOS
• Version: jj 0.16.0

[khionu]

This could probably be adaptive. There's likely a way we could measure, say, 200 redraws, and if they take longer than 1s, we could switch on a rate limit.

Addendum: As long as we're flushing each time, the buffer write should be synchronous after the draw, so that would give us the measure

[dpc]

It could, but I doubt anyone really needs FPS-game-like progress indication feedback. 10/s would probably both appear sufficiently smooth and not use too much badwidth no matter if used locally, over ssh, Tor, serial port, homing pigeon. It might struggle over smoke signals, I guess, due to really low bandwidth. But not exactly common use-case.

[necauqua]

Tor [..] homing pigeon

Idk man, some tor connections are incredibly slow.
And IPoAC has decent effective bandwidth but the ping is horrendous

[dpc]

It seems to me that here the biggest issue is the amount of data piling up to be delivered to the client. It stack on top of the normal latency. Enabling ssh compression might help a lot (someone suggested in on Discord).

BTW. Personally 1/s is real-time-enough for me anyway.

[khionu]

I like very smooth CLI rendering like JJ does, myself, and would be saddened if it were gone entirely. It may not be necessary, but it's pleasant, and locally it's perfectly fine.