Skip to content

Latest commit

 

History

History
92 lines (66 loc) · 5.64 KB

synchronized-output.md

File metadata and controls

92 lines (66 loc) · 5.64 KB

Synchronized Output

Original article was a gist, found here.

Alternate words to this feature has been:

  • Batched Rendering
  • Synchronized Updates
  • Synchronized Output

But they all mean the same.

Synchronized output is merely implementing the feature as inspired by iTerm2 synchronized output, except that it's not using the rare DCS but rather the well known SM ? and RM ?. iTerm2 has now also adopted to use the new syntax instead of using DCS.

Semantics

When rendering the screen of the terminal, the Emulator usually iterates through each visible grid cell and renders its current state. With applications updating the screen a at higher frequency this can cause tearing.

This mode attempts to mitigate that.

When the synchronization mode is enabled following render calls will keep rendering the last rendered state. The terminal Emulator keeps processing incoming text and sequences. When the synchronized update mode is disabled again the renderer may fetch the latest screen buffer state again, effectively avoiding the tearing effect by unintentionally rendering in the middle a of an application screen update.

Feature detection

Use CSI ? 2026 $ p to query the state of the (DEC) mode 2026. This works for any private mode number. If you get nothing back (DECRQM not implemented at all) or you get back a CSI ? 2026 ; 0 $ y then synchronized output is not supported. See DECRQM (request) and DECRPM (response) for more details.

DECRPM can respond with different values.

Value Documentation Relevance for synchronized output mode ?2026
0 Mode is not recognized not supported
1 Set supported and screen updates are not shown to the user until mode is disabled
2 Reset supported and screen updates are shown as usual (e.g. as soon as they arrive)
3 Permanently set undefined
4 Permanently reset not supported

Using the feature

Use CSI ? 2026 h to enable batching output commands into a command queue.

Use CSI ? 2026 l when done with your current frame rendering, implicitly updating the render state by reading out the latest grid buffer state.

Notation

Some developers name the beginning and end of such a synchronized frame (and therefore the instance)

  • BSU (begin synchronized update, CSI ? 2026 h), and
  • ESU (end synchronized update, CSI ? 2026 l).

Timeout

So far there is no real concensus if and if so how long a timeout should be. The toolkit/application implementer should keep this in mind. However, a too short timeout (maybe due to a very slow connection) won't be worse than having no synchronized output at all.

Adoption State

Support Terminal/Tookit/App Notes
✅ Alacritty alacritty#96
✅ BossTerm v1.0.54
✅ Contour
✅ bubbletea charmbracelet/bubbletea#1320
✅ foot
✅ ghostty commit
✅ iTerm2
✅ Jexer
✅ kava karlstav/cava#576
✅ Kitty commit
unknown Konsole
✅ mintty
✅ notcurses notcurses#1582
unknown st
unknown urxvt
not yet VTE / gnome-terminal gitlab/vte#15
✅ Warp warp#2185
✅ Wezterm wezterm#882
✅ Windows Terminal wt#18826
✅ xterm.js xterm.js#3375
✅ (see notes) st via patch: https://st.suckless.org/patches/sync/
✅ Zellij zellij-org/zellij#2977

In case some project is adding support for this feature, please leave a comment or contact me, so we can keep the spec and implementation state table up to date.