starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Implement synchronized update control sequences #11493

New Issue
Closed
opened 2026-01-31 02:49:11 +00:00 by claunia · 19 comments
claunia commented 2026-01-31 02:49:11 +00:00
Owner
Copy Link

Originally created by @Delta456 on GitHub (Nov 19, 2020).

Originally assigned to: @lhecker on GitHub.

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
Originally created by @Delta456 on GitHub (Nov 19, 2020). Originally assigned to: @lhecker on GitHub. <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> # 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 <!-- A clear and concise description of what the problem is that the new feature would solve. Describe why and how a user would use this new functionality (if applicable). --> ```[tasklist] ### Tasks ```
claunia added the Product-ConhostIssue-TaskIn-PRArea-VTNeeds-Tag-Fix labels 2026-01-31 02:49:12 +00:00
claunia commented 2026-01-31 02:49:13 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Nov 19, 2020):

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 conhost, and then at the end of the synchronized update, conhost would render once to the terminal. That makes sense to me.

@zadjii-msft commented on GitHub (Nov 19, 2020): 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 `conhost`, and then at the end of the synchronized update, conhost would render _once_ to the terminal. That makes sense to me.
claunia commented 2026-01-31 02:49:13 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Nov 19, 2020):

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.

@j4james commented on GitHub (Nov 19, 2020): 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.
claunia commented 2026-01-31 02:49:14 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Nov 19, 2020):

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

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:

  • We implement support for the DCS version of this sequence.
  • At the same time, as we add support for the DCS version, we add support for the DECSET/DECRST version.
  • At the same time, iTerm2 adds support for the DECSET/DECRST version.

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
@zadjii-msft commented on GitHub (Nov 19, 2020): > 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 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: * We implement support for the DCS version of this sequence. * _At the same time_, as we add support for the DCS version, we add support for the DECSET/DECRST version. * **At the same time**, iTerm2 adds support for the DECSET/DECRST version. 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](https://gitlab.freedesktop.org/terminal-wg/specifications/-/merge_requests/2)
claunia commented 2026-01-31 02:49:14 +00:00
Author
Owner
Copy Link

@gnachman commented on GitHub (Nov 19, 2020):

I am fine with this. I believe Kitty has also implemented support for this control sequence, so check with @kovidgoyal too.

@gnachman commented on GitHub (Nov 19, 2020): I am fine with this. I believe Kitty has also implemented support for this control sequence, so check with @kovidgoyal too.
claunia commented 2026-01-31 02:49:14 +00:00
Author
Owner
Copy Link

@kovidgoyal commented on GitHub (Nov 20, 2020):

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.

@kovidgoyal commented on GitHub (Nov 20, 2020): 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.
claunia commented 2026-01-31 02:49:15 +00:00
Author
Owner
Copy Link

@christianparpart commented on GitHub (Mar 26, 2021):

Just be careful when choosing numbers for the codes to not conflict with existing uses,

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.

@christianparpart commented on GitHub (Mar 26, 2021): > Just be careful when choosing numbers for the codes to not conflict with existing uses, 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.
claunia commented 2026-01-31 02:49:15 +00:00
Author
Owner
Copy Link

@kovidgoyal commented on GitHub (Mar 27, 2021):

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 commented on GitHub (Mar 27, 2021): 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.
claunia commented 2026-01-31 02:49:15 +00:00
Author
Owner
Copy Link

@christianparpart commented on GitHub (Mar 27, 2021):

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. ;-)

@christianparpart commented on GitHub (Mar 27, 2021): > 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. ;-)
claunia commented 2026-01-31 02:49:15 +00:00
Author
Owner
Copy Link

@christianparpart commented on GitHub (Jun 17, 2021):

@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. :)

@christianparpart commented on GitHub (Jun 17, 2021): @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. :)
claunia commented 2026-01-31 02:49:15 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Jun 17, 2021):

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).

@j4james commented on GitHub (Jun 17, 2021): 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).
claunia commented 2026-01-31 02:49:16 +00:00
Author
Owner
Copy Link

@christianparpart commented on GitHub (Jun 17, 2021):

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.

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. :)

@christianparpart commented on GitHub (Jun 17, 2021): > 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. 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](https://gist.github.com/christianparpart/d8a62cc1ab659194337d73e399004036). @j4james I can't await adding you (your branch / PR) once ready to it, too. Looking forward to it. :)
claunia commented 2026-01-31 02:49:16 +00:00
Author
Owner
Copy Link

@gnachman commented on GitHub (Jun 26, 2021):

I'm happy to do DECSET 2026. I've been busy, but will do it now.

@gnachman commented on GitHub (Jun 26, 2021): I'm happy to do DECSET 2026. I've been busy, but will do it now.
claunia commented 2026-01-31 02:49:16 +00:00
Author
Owner
Copy Link

@christianparpart commented on GitHub (Jun 26, 2021):

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.

@christianparpart commented on GitHub (Jun 26, 2021): > 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.
claunia commented 2026-01-31 02:49:16 +00:00
Author
Owner
Copy Link

@gnachman commented on GitHub (Jun 26, 2021):

Done in commit f7efeb4bbaa5ba2796f94c3bab32e5c64ee9c743

@gnachman commented on GitHub (Jun 26, 2021): Done in commit f7efeb4bbaa5ba2796f94c3bab32e5c64ee9c743
claunia commented 2026-01-31 02:49:16 +00:00
Author
Owner
Copy Link

@Delta456 commented on GitHub (Jun 26, 2023):

Any updates or progress on this?

@Delta456 commented on GitHub (Jun 26, 2023): Any updates or progress on this?
claunia commented 2026-01-31 02:49:17 +00:00
Author
Owner
Copy Link

@Delta456 commented on GitHub (Apr 23, 2025):

@DHowett @lhecker Thank you so much for implementing this long due feature 🙏

@Delta456 commented on GitHub (Apr 23, 2025): @DHowett @lhecker Thank you so much for implementing this long due feature 🙏
claunia commented 2026-01-31 02:49:17 +00:00
Author
Owner
Copy Link

@ldemailly commented on GitHub (Aug 10, 2025):

So I am still seeing heavy flickering unique to windows terminal... yet this is closed as fixed... should I open a new issue then

Anyone else seeing it not working ?

@ldemailly commented on GitHub (Aug 10, 2025): So I am still seeing heavy flickering unique to windows terminal... yet this is closed as fixed... should I open a new issue then Anyone else seeing it not working ?
claunia commented 2026-01-31 02:49:17 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Aug 10, 2025):

It hasn't been released yet, unless you're using the Canary channel!

@DHowett commented on GitHub (Aug 10, 2025): It hasn't been released yet, unless you're using the Canary channel!
claunia commented 2026-01-31 02:49:17 +00:00
Author
Owner
Copy Link

@ldemailly commented on GitHub (Aug 10, 2025):

Ah that gives me hope - so even the "Terminal Preview" from store app doesn't have that:

Windows Terminal Preview
Version: 1.23.12102.0

@ldemailly commented on GitHub (Aug 10, 2025): Ah that gives me hope - so even the "Terminal Preview" from store app doesn't have that: Windows Terminal Preview Version: 1.23.12102.0
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-VT In-PR Issue-Task Needs-Tag-Fix Product-Conhost
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#11493
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?