WTH is it with some requirements for "advanced" terminal emulators?

GTK Ptyxis and iirc kgx do it with GNOME GSK_RENDERER=vulkan default
Understood, but I think my question is more "why". For my adult life (ok some may say I'm not adult yet) terminal windows are text, perhaps ASCII art, escape sequences (even real vt100 had some level of support there) and ability to support curses.
Why need a 3d renderer to do 2d stuff?
 
Better performance, not too much as latency is higher on the GPU accelerated terminals. But if you cat a big file, it scroll so fast that you can not read it.
 
As long as you stay in character mode everything ok.
Problems start when you go to "graphical mode". I never could get working "ssh -X" or "vnc" work with neovim or vscode. Too slow to be of use.
 
It is more using a GPU (vs a CPU) than use of 3D rendering. On high dpi screens, once you use larger openfont/TTF fonts instead of bitmap ones, you can get noticeable better performance with a GPU than a CPU. This may not matter to typical users of these forums.....
I feel stuff like glamor doing 2D/everything -> 3D on older GPUs that have hardware 2D paths is less-efficient and only done for development ease (every GPU has 3D, Wayland doesn't support Xorg DDX for the 2D paths, newer AMD GPUs don't have 2D VCN -> GCN+)

Stuff on GNOME starts up faster with GSK_RENDERER=cairo vs vulkan/opengl for me with Wayland, and Xfce I use Intel DDX instead of modesetting/glamor (I think Skylake has 2D or maybe its blt?). On an old arcade computer with Radeon HD 2400 it handled fullscreen Stepmania 5 better with radeon/EAX vs modesetting/glamor (not sure why though since SM was exclusive-fs OpenGL and LXDE no-compositor; maybe SM5 could use 2D for certain things?)
 
As long as you stay in character mode everything ok.
Problems start when you go to "graphical mode". I never could get working "ssh -X" or "vnc" work with neovim or vscode. Too slow to be of use.
What does that graphical "mode" have to do with the terminal in use?
 
^ the apps tunneled aren't using X intristic which makes them a hell for network transport. It's like trying to tunnel a real OpenGL game in a windowed mode over X11.

The same would apply to Vulkan/OpenGL rendered terminals.
 
Good question. Lets say i do "ssh -X" will the output not first try to output in local terminal. Even a picture an icon , i can be wrong here .
IIRC, all -X does is allow ssh to serve as an X11 protocol tunnel: nothing more, nothing less. for xterm text it's kind of irrelevant. It really only has value if you remotely spawn an X11 application, but beware if you do...many X11 apps are not designed to well handle remote display, especially if they are bitmap graphics heavy.
 
IIRC, all -X does is allow ssh to serve as an X11 protocol tunnel: nothing more, nothing less. for xterm text it's kind of irrelevant. It really only has value if you remotely spawn an X11 application, but beware if you do...many X11 apps are not designed to well handle remote display, especially if they are bitmap graphics heavy.
You are not wrong, I think there is also a -Y which is same thing but does not do the security extensions. I routinely do this $WORK computer is a laptop that I hate the ergonomics of, but since working from home I ssh from my desktop with nice big monitors to it, open an xterm or two, then at most emacs. So not heavily graphic applications and they work fine. But I learned to not spawn firefox and try to display remotely a long time ago.
 
I use remote X11 for things like Chrome regularly. Not to randomly browse the web, but for example to authorize Claude Code. Works just fine.

Bitmaps are fine for X11 forwarding. What isn't find is GLX and anything usng SDL for bitmaps, such as (annoyingly) qemu's console. But you can solve that by running in Xpra.
 
I cannot get complex applications to tunnel fast. On a 1 Gbit LAN, accessing Kdevelop on work laptop from home computer. The UI is always laggy.
Try 10 Gbit/s Ethernet. But with most machines you should also switch to a faster cipher for ssh.

Watch in top(1) whether your bottleneck is ssh CPU time.
 
re - tunneling X11

for me the problems start with most apps that are gtk based. and forget about tunneling anything gnome. if it's not the dog slow throughput, then it's the ridiculous service layers like dbus...or the naive juvenile attempts of the gnome developers who never consider an app might be run remotely so they don't handle configuration metadata in a network neutral manner.

Sometimes I miss motif...sometimes. LOL
 
  • Like
Reactions: mer
I never X tunneled; servers didn't have X, and I figure remote computers to either have a physical K/M/monitor to do GUI stuff on directly, or need Sunshine/high-end 3D streaming tech for serious low-latency/high-quality/framerates.
 
I never X tunneled; servers didn't have X, and I figure remote computers to either have a physical K/M/monitor to do GUI stuff on directly, or need Sunshine/high-end 3D streaming tech for serious low-latency/high-quality/framerates.

I use x11 apps on plenty headless FreeBSD machines that have no X11 server of their own.

Examples: xbiff, ledbiff (uses keyboard LEDs to indicate you have mail), xload, xterm.

And of course the already mentioned remote Chrome or FIrefox to activate Claude Code.
 
Oh great. Linux now starts messing with their VT mechanism. You know, the one that had nothing wrong with it:


I wonder whether this new toy is compatible with Claude Code, homebrew and pip.
Not sure what openSUSE is using, but I wonder how KMSCON interacts with drm_kms_helper.fbdev_emulation=0; been using that for a bit for faster boots :cool: (TTY switching seemingly doesn't work but haven't needed that yet with GNOME 48+; Xfce/X11 with LightDM doesn't show on external HDMI with that but outputs fine from Xfce/after log-in)
 
Oh, great. Apparently using kitty for everyday work is not in the cards:

Code:
$ tmux -L ollamasrv1a new-session -A -s ollamasrv1a /bin/bash
missing or unsuitable terminal: xterm-kitty

Kitty also seems a bit copy'n'paste challenged, at least on macOS.
 
Try 10 Gbit/s Ethernet. But with most machines you should also switch to a faster cipher for ssh.

Watch in top(1) whether your bottleneck is ssh CPU time.

Nah. That would require having USB 10GBit interface for the laptop, and VNC works better anyway
The problem is, 2000x1000 window in 32-bit color should completely redraw in 10-15 FPS range.
I will inspect the negotiated ciphers next time but default with RHEL and FreeBSD should be an AES variant where a 1 GBit load should be taken care of by AESNI.
 
I wonder whether this new toy is compatible with Claude Code, homebrew and pip.
That is not the question. The question is if Claude, homebrew or pip (or whatever) is compatible with $SHINY_NEW_TOY (at least I see them looking at things like that)
 
Back
Top