Conversation

Notices

1. Bernie (codewiz@mstdn.io)'s status on Tuesday, 12-Sep-2023 11:36:41 UTC Bernie

   vtebench results for #Konsole (left), #Wezterm (center) and #Alacritty (right).

   All three were running full-screen and configured to use the same font and approximately the same point size (11.0).

   Wezterm was built from sources using "cargo build --release". The other two are distro binaries from #Fedora Rawhide.

   Note that Wezterm (the slowest of the three) has a gradient background). It's also a git snapshot that recently switched its default rendering backend to #WebGPU.

   • Bernie (codewiz@mstdn.io)'s status on Monday, 25-Sep-2023 08:44:39 UTC Bernie

     in reply to

     • Wez Furlong :terminal:

     @wez Indeed, all benchmarks get better scores with batching disabled (left) compared to the default 3 ms delay (right).

     But how would this internal flush delay affect vtebench's measurements, which are presumably based on how fast it can write stuff to the pty?

     I mean, it's not like the terminal process would sit idle for 3 ms without processing further input...

   • Wez Furlong :terminal: (wez@fosstodon.org)'s status on Monday, 25-Sep-2023 08:44:40 UTC Wez Furlong :terminal:

     in reply to

     @codewiz note that wezterm deliberately delays escape sequence processing in order to get better batching and less tearing with non-synchronized output. You can configure the batching delay using the mux_output_parser_coalesce_delay_ms option. See https://github.com/wez/wezterm/issues/2443 for more information.

   • Wez Furlong :terminal: (wez@fosstodon.org)'s status on Monday, 25-Sep-2023 14:47:40 UTC Wez Furlong :terminal:

     in reply to

     @codewiz In wezterm, there is a separate pty reading thread that parses the incoming data before handing it to the model. That delay catches fragmented writes to reduce flicker and tearing when an application repaints the whole screen but uses small writes to do so.

     After each read, unless we are over mux_output_parser_buffer_size (128k by default) we wait that 3ms to see if more data is following to batch it together.

     Using https://gitlab.com/gnachman/iterm2/-/wikis/synchronized-updates-spec skips this logic.

   • Bernie (codewiz@mstdn.io)'s status on Monday, 25-Sep-2023 14:47:40 UTC Bernie

     in reply to

     • Wez Furlong :terminal:

     @wez I find this last paragraph intriguing:

     "Could ncurses-based applications take advantage of this without modifying ncurses? Should ncurses reasonably be modified to support this?"

     If apps start using BSU + ESU around ncurses calls, then ncurses can never use them internally, since they wouldn't nest.

     Keeping a nest counter sounds like a recipe for trouble when apps crash.

     So when are we adding escapes for XGL with double buffering and XShm? 😂