extreme flicker when building with many threads

[pennae]

it seems that nom updates its display way too often. builds that produce a lot of output very quickly (eg because they're running on many threads) flicker to the point of being painful to look at, or at the very least unreadable (tested on alacritty and urxvt). not sure whether this can be fixed by just slowing down the output thread or if ncursesery is needed.

[maralorn]

Hey, so I’d first say that this is kinda a known issue. It is caused by the simplistic approach nom takes.
One aim that I had designing nom was that the scrollback buffer would be exactly the same as without running nom.
For this on every frame nom

1. deletes its own output (so that it’s cursor is at the bottom of the nix output
2. prints the new nix output
3. prints it’s own output again.
   So yeah, the nom display flickers. Although I have to say on my systems it’s maybe annoying but not unreadable.

The logic is here:

nix-output-monitor/src/IO.hs

Line 46 in 48d5447

race_ (concurrently_ (threadDelay 20000) waitForInput) (threadDelay 1000000)

The 20000 means, that we rewrite at most after 0.02s and the 1000000 that we rewrite at the latest after 1s. (threadDelay takes microseconds.)

I don‘t know how comfortable you are with Haskell. Maybe you want to play around with tweaking this numbers to see what works better for you?

I suspect that going up to 0.05s would probably be no issue. Maybe we can even find a complicated formula where we throttle the output while we are printing more lines.

But yeah ncursesery would probably also be an option.

[pennae]

slowing down updates did not help much at all, the flickering was still there even at one update per second. did find a different fix though that seems to work :)

[Luflosi]

I still see a little flickering.

The proper solution to this issue is to follow the synchronized updates spec. DECSET/DECRESET should be used instead of BSU/ESU. This basically begins a "transaction" before nom starts modifying the screen and ends it after nom is done.
If this were implemented, no intermediate state will be visible in terminals that support this spec as the redraws would be atomic.

[maralorn]

@Luflosi the flickering is an annoying topic. In theory the spec says very clearly which drawing events should trigger a redraw and which ones not and I tried painstakingly to trigger as few redraws as possible, but for one there is no way to push lines out-of the terminal at the top without triggering redraws and in my experience many emulators don’t behave consistently and basically redraw whenever they like.

Having a way to begin and end a transaction would be fricking awesome. However do you know which terminals support this spec and can we use this in a compatible way for terminals which don’t support it?

[Luflosi]

I found https://gist.github.com/christianparpart/d8a62cc1ab659194337d73e399004036 which lists kitty, Alacritty, iTerm2, Wezterm and foot among the terminal emulators that support this.
I think you don't need any feature detection as unsupported CSI sequences are ignored AFAIK.

[maralorn]

I implemented this in #172. This was far more trivial than I thought. Hopefully this fixes flickering in most modern terminals.