-
Notifications
You must be signed in to change notification settings - Fork 795
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
Comments
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:
|
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). |
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 |
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. |
@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. |
@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. |
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
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
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
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
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.
The text was updated successfully, but these errors were encountered: