Implement synchronized update control sequences #8331
Comments
Delta456
added
the
Issue-Feature
ghost
added
Needs-Triage
|
Yea okay, this seems well thought out. I like that there are contingincies included for "what happens when the client app disconnects before sending an <end>". Plus, I think we did add support for DCS sequences relatively recently, so this shouldn't be too bad. Part of the trick here is gonna be conpty, and the way we use that to render the effects of output on the console buffer. I'd guess that this would have to be implemented in |
zadjii-msft
added
Area-VT
|
Note that this idea was discussed in terminal-wg a while back, and I think it was generally agreed that a DCS sequence was a bad choice for this. One of the benefits of this functionality is that it shouldn't require feature detection - if a terminal doesn't support it, then you just don't get the optimisation. However, that's not the case if you're using a DCS sequence, because there are a number of terminals that will output garbage if you send them an unrecognised DCS. So now an app can't really use this functionality unless they first determine whether it's supported somehow. As is typical for terminal-wg, there was no official conclusion to the discussion, but the general consensus seemed to have been that a DECSET private mode sequence would be preferable, and the mode number that was settled on was 2026. I know at least one terminal has implemented synchronized updates via mode 2026, and at least one application is using that mode. Also I know @gnachman has said "If I had it to do over again, I'd push for DECSET/DECRST", but he hasn't actually agreed to supporting the proposed mode in iTerm2 as far as I'm aware. If we're going to implement this, I'd much rather we used a DECSET mode than DCS, but I'd also like to have seen some definite commitment to that approach from people like iTerm2. |
Guh, I hate that. Maybe we come up with an agreement between us and iTerm2 to move forward onto a DECSET/DECRST implementation. We'd obviously have to still support the DCS version of the sequence, but maybe we can help push the ecosystem forward a bit here. Here's what I'm thinking:
At this point, we'd update any existing documentation to suggest that app developers use the new version of the sequence, and the old one is deprecated. Terminal emulators that haven't been updated with support for the new sequence will silently ignore it. Apps that aren't updated to use the new sequence will still continue to work (and will start working on the console/Terminal). This would obviously require buyoff from @gnachman, but this seems like a reasonable path, and one that would work cross-platform. Thoughts? notes: terminal-wg pr |
|
I am fine with this. I believe Kitty has also implemented support for this control sequence, so check with @kovidgoyal too. |
|
You can go ahead and use DECSET/DECRESET if it floats your boat. Since you are also implementing support for the DCS version, I dont really care. I will note that the only terminals that dont support DCS sequences are Apple's and the Linux kernel console. Using DECSET/DECRESET means that no future modifications can be made to the protocol to implement additional features. Which will mean in the long term that DECSET/DECRESET will be the deprecated ones, but hey, no harm in having them, just another redundant code path. Just be careful when choosing numbers for the codes to not conflict with existing uses, which was one of the motivations for choosing DCS in the first place. |
DHowett
changed the title
DHowett
changed the title
DHowett
removed
the
Needs-Triage
I like to compare that feature a little bit to double buffering in graphics APIs, such as OpenGL (first released in 1992), wich is also there to avoid tearing effects. That standard had never changed. So i am pretty confident it won't need any feature extension here, too. |
|
That's not a valid comparison. OpenGL's double bufferring buffers a single thing, a pixel buffer, and over a fast local link. In the terminal case you are bufferring terminal state beyond just what is drawn on the screen and over latency variable, lossy networks. |
@kovidgoyal i do not want to fight over little differences when I explicitly did not say equal but like. That would be way to off-topic. Feel free to ignore my opinion. ;-) |
|
@zadjii-msft good morning. I'd like to ask if there there had been actually any brainstorming progress on the msft side of the fence? I stilll do also think that DECSM/DECRM are the right choice, and I came back to see if here was any progress until then. :) |
|
I actually hacked together a basic implementation of this a while back (just the mode 2026 approach) which I've been using in my local fork. We didn't have the ability to do DCS at the time, and I was also waiting to see what iTerm2 would do. But I suspect now that gnachman has changed his mind about supporting mode 2026 (it would have taken all of 3 lines of code if he was going to do it). So if it were up to me, I'd say we should just do the mode and ignore the DCS approach. Supporting both will push apps to use DCS, which is exactly what we want to avoid. Even if we don't care about all the other terminals that will be negatively effected by the use of DCS (which I can assure you is more than two), the Windows console itself didn't support DCS until very recently. So there are still likely to be a significant number of users on an older version of Windows that'll break if sent a DCS sequence, and upgrading is not always an option (I know, because several of my computers are on older versions that aren't being offered upgrades). If it turns out there are actually apps using the DCS sequence that can't be persuaded to add support for the mode, then we can always reconsider adding a DCS alias later (but preferably when the #6328 fix is more widely deployed). |
I am all in, and absolutely agree with you on that decision. For reference, I've put together the spec as well with the (more interestingly maybe) list of supporting software for the "synchronized rendering" feature here. @j4james I can't await adding you (your branch / PR) once ready to it, too. Looking forward to it. :) |
|
I'm happy to do DECSET 2026. I've been busy, but will do it now. |
I am really happy to hear from you. Looking forward to it. |
|
Done in commit f7efeb4bbaa5ba2796f94c3bab32e5c64ee9c743 |
This will conceal the following message: erresc: unknown private set/reset mode 2026 See also: https://gitlab.freedesktop.org/terminal-wg/specifications/-/merge_requests/2#note_579597 microsoft/terminal#8331 dankamongmen/notcurses#1582 xtermjs/xterm.js#3375 kovidgoyal/kitty@5768c54 https://gist.github.com/christianparpart/d8a62cc1ab659194337d73e399004036
|
Any updates or progress on this? |
Description of the new feature/enhancement
https://gitlab.com/gnachman/iterm2/-/wikis/synchronized-updates-spec
The goal of synchronized updates is to avoid showing a half-drawn screen, such as while paging through a document in an editor.
A new control sequence is proposed that indicates the beginning and end of a update. No new content should be rendered by the terminal emulator until the update ends, at which point any changes made during the update should be applied atomically.
The purpose of this sequence is to provide a hint to the terminal emulator about how to draw atomically. If it turns out to be too difficult to do under some particular input, the hint can be safely ignored
Tasks
The text was updated successfully, but these errors were encountered: