Originally posted by S.Pam
View Post
Announcement
Collapse
No announcement yet.
Linux Terminal Emulators Have The Potential Of Being Much Faster
Collapse
X
-
Originally posted by reba View Post
1) when you change font size, it should keep the same dimensions in chars row/cols (i.e. make the window bigger or smaller). It's nice that foot reflows text when you resize, unlike xterm which will truncate it's buffers.
2) need some sort of menu for the occasional runtime settings flipping. Disabling scroll to bottom on tty ouput is the only one I really use from time to time on xterm.
3) I want my xterm replacement to have tabs and hopefully split terminals as well. (I'd consider using screen/tmux/zellij if I was still using a vt220, but since I have a graphical desktop, I want to use it, and not replace my GUI with ascii art)
Comment
-
Originally posted by S.Pam View PostI'm pretty happy with Kitty. It's my go to terminal these days.
- Likes 3
Comment
-
- Likes 2
Comment
-
Originally posted by Snaipersky View Post
I would think that everything could be reasonably contained in a session###.var containing variables and command history, and a session###.buf containing the saved output. No shell integration required, just a way to select a session (and maybe snapshot it) in the terminal.
Comment
-
Originally posted by elduderino View Post/wave Author of termkit stuff here
First off, the Termkit prototype was just for me to figure out what "best case" performance would be while I go try to fix bits of VTE. It's good to have a trajectory to shoot for when doing optimization work.
There is nothing wrong with your setup.
The VTE port to GTK 4 was _VERY_ minimal and basically just used a Cairo fallback render node in GTK 4. That is worst possible case because the OpenGL renderer in GTK 4 has to upload the surface texture on every frame. This is precisely what I set out to fix (because I consume VTE for GNOME Builder's terminal as well). The patches I put together for VTE (which still need work to be upstreamed) use GskTextNode with the goal to get a considerable amount of caching and use the glyph texture atlas properly. Doing so results in a color+blit as a single GL shader program. You don't even have to change programs to draw the rectangles, emoji, etc. It's one large VBO and glDrawArrays().
Generally speaking, I don't work on VTE except the most basic of patches, but I did write a lot of GTK 4's OpenGL renderer, wrote one of the GDK platform back-ends, helped made text scrolling smooth at high frame rates, and the profiler we use to optimize the compositor and apps in GNOME. So I have very practical experience at what to do to "cut through the bullshit" at every one of those layers.
A lot of emulators out there focus on how to do the drawing really fast. Well we already have that solved in GTK. Some of them focus on tracking damage areas to keep updates minimal. Again, we already have that for free in GTK 4 based on the render tree diffs. So again, don't waste time doing that work.
The other optimizations are all pretty normal stuff. Keep data-structures flatter to avoid pointer chases. Read PTY data directly into your chunked ring buffer. Be very careful in your VT parser to avoid doing things per-character. Keep styling attributes in as fast to store format as you can so you can skip over the vast majority that never gets displayed. Only wrap text for the region you can see, do the rest in the background. Keep render nodes around for an extra frame so you can get _VERY_ fast render tree diffs from gsk_render_node_diff() using pointer equality... Anyway, nothing too outrageous IMO.
I suppose the sources or a deb package are not available for a small test run?
- Likes 2
Comment
-
Originally posted by reba View Post
This seems to be dependend on the terminal window size as it stretches the video.
Setting
- all the windows to the same sizes by "Win+CursorRight"
- having a same-ish font size so the same amount of content is shown
- all CPU governors set to powersave
- all CPU cores fixed to max 400 MHz
- best of two runs
results in:
...
Comment
-
Originally posted by EphemeralEft View Post
I love Kitty, but it’s incompatible with my peripherals; it constantly presses my keys and turns off my monitor. And the garbage collection is also pretty unpleasant. If the interface wasn’t so nice, I’d have switched to Doggy.
- Likes 1
Comment
Comment