Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for Synchronized Output (Mode 2026) #850

Open
talios opened this issue Nov 1, 2023 · 6 comments
Open

Support for Synchronized Output (Mode 2026) #850

talios opened this issue Nov 1, 2023 · 6 comments
Labels
enhancement New feature or request

Comments

@talios
Copy link

talios commented Nov 1, 2023

Is your feature request related to a problem? Please describe.

Recently I've been beta testing the new Ghostty terminal (https://mitchellh.com/ghostty), whose super fast performance has started revealing various refresh/tearing issues in other applications.

When running the Dagger (dagger.io) CI tool locally, and more so using experimental UI, I noticed A LOT of screen flicker, after discussing this on both the Ghostty and Dagger discords, I was pointed here.

Ghostty supports the Synchronized Output spec (https://gist.github.com/christianparpart/d8a62cc1ab659194337d73e399004036, inspired from iTerm) which aims to provide a contract between terminals and applications to reduce screen tearing and apparent UI flickering.

Describe the solution you'd like

I'm not a bubbletea user myself, but a user of tools using bubbletea, but I'd love to see the library adopt support for Synchronised Output and makes many users a lot less... tearful.

@talios talios added the enhancement New feature or request label Nov 1, 2023
@meowgorithm meowgorithm changed the title Support for Synchronized Output Support for Synchronized Output (Mode 2026) Nov 1, 2023
@meowgorithm
Copy link
Member

Hi! Thanks for filing; this makes sense to me. No ETA on when we can commit to it, though at first read it looks like implementation would be pretty straightforward.

We're actually also Ghostty users, though I personally haven't seen much jank yet. I will say that traditionally you'll see some lag when redrawing very large TUIs on very large windows, and we do plan to address that in other ways as well.

Few more questions, which will help us measure results a bit:

  1. Are you using very large terminal?
  2. Any chance you upload a screencast of the behavior?
  3. Which OS are you using?
  4. Are you seeing this with any other tools built on Bubble Tea? Asking mostly because at first glance Dagger looks like it may take a degree of setup before we can actually see some UI from it (I could be wrong through).

@talios
Copy link
Author

talios commented Nov 1, 2023

Hi, just a quick response and its 3:30am (I couldn't sleep).

This is a link to my ghostty discord message/video: https://discord.com/channels/1005603569187160125/1005603569711452192/1168783411968745482 - I can post that elsewhere in the morning if not accessible.

The terminal window isn’t that large even even small term sizes produce the effect.

This is on macOS Sonoma (Intel).

@meowgorithm
Copy link
Member

Got it, thank you. Attaching the video here for reference. It looks like the top and bottom are both different builds of Ghostty. Is that correct?

Hope you get some sleep!

Ghostty_-__I_s_s_smx3-integration.mp4

@muesli
Copy link
Contributor

muesli commented Nov 1, 2023

I do have a patch implementing synchronized output. I've never followed up on it, as so far I had not seen a terminal where it would make a difference, but if ghostty benefits from this, I'll happily open a PR.

@talios
Copy link
Author

talios commented Nov 1, 2023

@meowgorithm the bottom version was WezTerm, with Ghostty at the top - which as Mitchel pointed out, still shows some tearing but not as much as Ghostty - mostly cause Ghostty is much more responsive.

@ctrox
Copy link

ctrox commented Jan 19, 2024

@muesli Would you mind posting that patch or is it already pushed somewhere? I observed similar issues in Alacritty on Linux, which apparently should support synchronized output and I would be very interested to see if this helps.

aymanbagabas added a commit that referenced this issue Aug 12, 2024
Currently, Bubble Tea uses a simple lookup table to detect input events.
Here, we're introducing an actual input sequence parser instead of
simply using a lookup table. This will allow Bubble Tea programs to read
all sorts of input events such Kitty keyboard, background color, mode
report, and all sorts of ANSI sequence input events.

Supersedes: #1014
Related: #869
Related: #163
Related: #918
Related: #850
Related: #207
aymanbagabas added a commit that referenced this issue Aug 12, 2024
Currently, Bubble Tea uses a simple lookup table to detect input events.
Here, we're introducing an actual input sequence parser instead of
simply using a lookup table. This will allow Bubble Tea programs to read
all sorts of input events such Kitty keyboard, background color, mode
report, and all sorts of ANSI sequence input events.

Supersedes: #1079
Supersedes: #1014
Related: #869
Related: #163
Related: #918
Related: #850
Related: #207
aymanbagabas added a commit that referenced this issue Aug 12, 2024
Currently, Bubble Tea uses a simple lookup table to detect input events.
Here, we're introducing an actual input sequence parser instead of
simply using a lookup table. This will allow Bubble Tea programs to read
all sorts of input events such Kitty keyboard, background color, mode
report, and all sorts of ANSI sequence input events.

Supersedes: #1079
Supersedes: #1014
Related: #869
Related: #163
Related: #918
Related: #850
Related: #207
aymanbagabas added a commit that referenced this issue Aug 19, 2024
Currently, Bubble Tea uses a simple lookup table to detect input events.
Here, we're introducing an actual input sequence parser instead of
simply using a lookup table. This will allow Bubble Tea programs to read
all sorts of input events such Kitty keyboard, background color, mode
report, and all sorts of ANSI sequence input events.

This PR includes the following changes:
- Support clipboard OSC52 read messages (`OSC 52 ?`)
- Support terminal foreground/background/cursor color report messages
(OSC10, OSC11, OSC12)
- Support terminal focus events (mode 1004)
- Deprecate the old `KeyMsg` API in favor of `KeyPressMsg` and
`KeyReleaseMsg`
- `KeyType` const values are different now. Programs that use int value
comparison **will** break. E.g. `key.Type == 13` where `13` is the
control code for `CR` that corresponds to the <kbd>enter</kbd> key.
(BREAKING CHANGE!)
- Bubble Tea will send two messages for key presses, the first of type
`KeyMsg` and the second of type `KeyPressMsg`. This is to keep backwards
compatibility and _not_ break the API
  - `tea.Key` contains breaking changes (BREAKING CHANGE!)
- Deprecate `MouseMsg` in favor of `MouseClickMsg`, `MouseReleaseMsg`,
`MouseWheelMsg`, and `MouseMotionMsg`
- Bubble Tea will send two messages for mouse clicks, releases, wheel,
and motion. The first message will be a `MouseMsg` type. And the second
will have the new corresponding type. This is to keep backwards
compatibility and _not_ break the API
  - `tea.Mouse` contains breaking changes (BREAKING CHANGE!)
- Support reading Kitty keyboard reports (reading the results of sending
`CSI ? u` to the terminal)
- Support reading Kitty keyboard and fixterms keys `CSI u`
- Support reading terminal mode reports (DECRPM)
- Bracketed-paste messages now have their own message type `PasteMsg`.
Use `PasteStartMsg` and `PasteEndMsg` to listen to the start/end of the
paste message.
- Bubble Tea will send two messages for bracketed-paste, the first is of
type `KeyMsg` and the second is of type `PasteMsg`. This is to keep
backwards compatibility and _not_ break the API
- Support more obscure key input sequences found in URxvt and others
- Support reading termcap/terminfo capabilities through `XTGETTCAP`.
These capabilities will get reported as `TermcapMsg`
- Support reading terminfo databases for key input sequences (disabled
for now)
- Support reading [Win32 Input Mode
keys](https://github.com/microsoft/terminal/blob/main/doc/specs/%234999%20-%20Improved%20keyboard%20handling%20in%20Conpty.md#win32-input-mode-sequences)
- Support reading Xterm `modifyOtherKeys` keys

TODO:
- [x] Parse multi-rune graphemes as one `KeyPressMsg` storing it in
`key.Runes`
- [x] Kitty keyboard startup settings and options
#1083
- [x] Xterm modify other keys startup settings and options
#1084
- [x] Focus events startup settings and options
#1081
- [x] Fg/bg/cursor terminal color startup settings and options
#1085

Supersedes: #1079
Supersedes: #1014
Related: #869
Related: #163
Related: #918
Related: #850
Related: #207
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants