Application synchronized updates / DECRQM

[dankamongmen]

https://gitlab.freedesktop.org/terminal-wg/specifications/-/merge_requests/2 (seen in the foot man page). hey @dnkl if you could invite me into that terminal-wg, i'd appreciate it.

[dnkl]

hey @dnkl if you could invite me into that terminal-wg, i'd appreciate it.

Would if I could, but I'm not a member...

[j4james]

I don't know how much of the thread on terminal-wg you've read, but note that the DCS sequence that was originally proposed is somewhat problematic, in that it produces garbage output on some terminals that don't recognise DCS, so it's not really safe to use by default.

As a result it was generally agreed that a DECSET private mode sequence would be preferable. That way you can use the sequence indiscriminately, and worst case it will be ignored on terminals that don't support it.

The proposed mode sequences are as follows:

CSI ?2026h indicates the start of a synchronized update
CSI ?2026l indicates the end of the update

[dankamongmen]

thanks for the tip, @j4james !

[dnkl]

Foot issue: https://codeberg.org/dnkl/foot/issues/459, PR: https://codeberg.org/dnkl/foot/pulls/461

[christianparpart]

I just came here as I wanted to see if notcurses does or will support that. I am currently trying to gather a list of terminals / toolkits / apps that do support it. And I hoped to be able to add you soon, too. Just to let you know, @dankamongmen :)

[dankamongmen]

yeah @christianparpart i'm intending to support it. reading over the spec more closely now (i'd just seen a summary, and liked the idea). oooh, i don't like this timeout business one bit =[

[dankamongmen]

most interesting to me would be using this to ensure graphic+text updates are performed at the same time (i would use it around each frame i draw, but the main benefit would be eliminating flicker in graphic+text cases). i don't see anything regarding graphics at https://gitlab.com/gnachman/iterm2/-/wikis/synchronized-updates-spec. what's the story there?

[dankamongmen]

so i'm taking a look at this spec, and it's not...necessarily what i would have done.

a few thoughts:

• is support discoverable? i'm not delighted about the idea of adding a header and footer to every frame that's just going to be thrown away. i see no method for discovery.
  • similarly, an incomplete VTxxx state machine might end up throwing away my input, it seems
• that timeout is anathema. for that alone, i'd not want to use this most of the time. people on wireless have multisecond hiccups all the time. that output is just going to be thrown away? that's furthermore going to force a user-initiated refresh (ctrl-L), because my idea of what's currently drawn will be invalid

i'd hope that when a terminal reads a frame in toto, the display is effectively automatic, at least most of the time. so i'm thinking i maybe only want to use this on frames larger than some size, with that size ideally being "the number of bytes that the terminal is prepared to display automatically" (which of course might not be defined).

i mean, plenty of apps may very well be changing a single cell and redrawing. that would currently map to a 2-byte frame in Notcurses. if i throw this around every frame, that's 700% overhead for a totally common case. erp!

[dankamongmen]

i mean i guess this is already implemented in a number of things, but here's what i would have liked:

• no timeout ideally, but whatever
• i send a query and find out if you support this
• if you do, great! i send an escape enabling it
• once enabled, nothing is displayed until receiving an escape flushing the output

that at least cuts the overhead. oh well. maybe this wouldn't work for reasons i don't understand.