flickering because ESC [?2026h/l isn't implemented #23191

Closed
opened 2026-01-31 08:34:57 +00:00 by claunia · 7 comments
Owner

Originally created by @ldemailly on GitHub (Apr 22, 2025).

Windows Terminal version

1.21,1.22,1.23

Windows build number

10.0.26100.3775

Other Software

golang

Steps to reproduce

go run fortio.org/terminal/brick@v0.33.0

use arrow keys, observe flickering

Expected Behavior

no flickering like most other terminal that handle ESC [?2026h and ESC [?2026l

Actual Behavior

flickering

Originally created by @ldemailly on GitHub (Apr 22, 2025). ### Windows Terminal version 1.21,1.22,1.23 ### Windows build number 10.0.26100.3775 ### Other Software golang ### Steps to reproduce go run fortio.org/terminal/brick@v0.33.0 use arrow keys, observe flickering ### Expected Behavior no flickering like most other terminal that handle ESC [?2026h and ESC [?2026l ### Actual Behavior flickering
claunia added the Issue-BugResolution-Duplicate labels 2026-01-31 08:34:57 +00:00
Author
Owner

@ldemailly commented on GitHub (Apr 22, 2025):

found on https://gist.github.com/christianparpart/d8a62cc1ab659194337d73e399004036#adoption-state a link to #8331

so maybe this is a dup of that 2020 issue, yet would be really useful to implement

@ldemailly commented on GitHub (Apr 22, 2025): found on https://gist.github.com/christianparpart/d8a62cc1ab659194337d73e399004036#adoption-state a link to #8331 so maybe this is a dup of that 2020 issue, yet would be really useful to implement
Author
Owner

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

Sure can: #18826 🙂
I'll close this as a dupe of #8331 though. /dup #8331

Thank you for your test case and neat little game! 😄

P.S.: I noticed that it doesn't use the alternate screen buffer. Unless that's intentional, that may be worth using. I also noticed that it continuously pushes the game contents into the scrollback of the terminal. I assumed that fortio would just CUP to 1;1 and then redraw from there. So, even without the alternate buffer, I guess it shouldn't scroll... right?

@lhecker commented on GitHub (Apr 23, 2025): Sure can: #18826 🙂 I'll close this as a dupe of #8331 though. /dup #8331 Thank you for your test case and neat little game! 😄 P.S.: I noticed that it doesn't use the alternate screen buffer. Unless that's intentional, that may be worth using. I also noticed that it continuously pushes the game contents into the scrollback of the terminal. I assumed that fortio would just CUP to 1;1 and then redraw from there. So, even without the alternate buffer, I guess it shouldn't scroll... right?
Author
Owner

@microsoft-github-policy-service[bot] commented on GitHub (Apr 23, 2025):

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@microsoft-github-policy-service[bot] commented on GitHub (Apr 23, 2025): Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report! <!-- Policy app identification https://img.shields.io/static/v1?label=PullRequestIssueManagement. -->
Author
Owner

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

I noticed that it doesn't use the alternate screen buffer. Unless that's intentional, that may be worth using.
Would that change flickering? The reason I don't use it is twofold:

  • I try to use only the minimal ansi codes I can to achieve the goal
  • I do like that the last screen/content is shown on exit
    but maybe I am missing something and happy to learm

I also noticed that it continuously pushes the game contents into the scrollback of the terminal.

Every refresh starts with clear screen so... it shouldn't be in scrollback ?

I assumed that fortio would just CUP to 1;1 and then redraw from there. So, even without the alternate buffer, I guess it shouldn't scroll... right?

After the clear screen it indeeds starts drawing at 1,1 - that's what it does for that game, for others it doesn't change areas of the screen that don't change

What do you mean should scroll?
But I just checked and indeed it's unique to windows terminal that every frame seems to be in scrollback, none of the other terminals do that - isn't it a bug in windows terminal?

@ldemailly commented on GitHub (Apr 23, 2025): > I noticed that it doesn't use the alternate screen buffer. Unless that's intentional, that may be worth using. Would that change flickering? The reason I don't use it is twofold: - I try to use only the minimal ansi codes I can to achieve the goal - I do like that the last screen/content is shown on exit but maybe I am missing something and happy to learm > I also noticed that it continuously pushes the game contents into the scrollback of the terminal. Every refresh starts with clear screen so... it shouldn't be in scrollback ? > I assumed that fortio would just CUP to 1;1 and then redraw from there. So, even without the alternate buffer, I guess it shouldn't scroll... right? After the clear screen it indeeds starts drawing at 1,1 - that's what it does for that game, for others it doesn't change areas of the screen that don't change What do you mean should scroll? But I just checked and indeed it's unique to windows terminal that every frame seems to be in scrollback, none of the other terminals do that - isn't it a bug in windows terminal?
Author
Owner

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

@lhecker want me to file a new issue about scrollback?

@ldemailly commented on GitHub (Apr 23, 2025): @lhecker want me to file a new issue about scrollback?
Author
Owner

@ldemailly commented on GitHub (Apr 24, 2025):

So I thought I could maybe reproduce it simply with something like

Write-Host "$([char]27)[2J$([char]27)[1;1Hone$([char]27)[2J$([char]27)[1;1Htwo"

but that actually works as expected (as in doesn't put "one" in the scrollback

so I am not sure why - maybe because brick does send a lot of data on that same page? or something makes it scroll even though it's not visible (extra write when at the bottom right?)

@ldemailly commented on GitHub (Apr 24, 2025): So I thought I could maybe reproduce it simply with something like ```powershell Write-Host "$([char]27)[2J$([char]27)[1;1Hone$([char]27)[2J$([char]27)[1;1Htwo" ``` but that actually works as expected (as in doesn't put "one" in the scrollback so I am not sure why - maybe because brick does send a lot of data on that same page? or something makes it scroll even though it's not visible (extra write when at the bottom right?)
Author
Owner

@ldemailly commented on GitHub (Apr 24, 2025):

nvm it does reproduce with this for instance:

Write-Host "$([char]27)[2J$([char]27)[1;1Hone`r`nprevious`r`n$([char]27)[2J$([char]27)[1;1Htwo`r`n"

will file a new issue

@ldemailly commented on GitHub (Apr 24, 2025): nvm it does reproduce with this for instance: ```powershell Write-Host "$([char]27)[2J$([char]27)[1;1Hone`r`nprevious`r`n$([char]27)[2J$([char]27)[1;1Htwo`r`n" ``` will file a new issue
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#23191