71–80 of 134 posts
Cool! Porting to the web is an interesting idea. I can’t help but imagine going back to the 70s and trying to show someone that yes, everyone has this full colour, mouse-supporting, GUI app platform accessible on any device and interlinked between billions of similar interactive documents from around the world… but it was really important that we set up a TTY. The smug (or horrified) look on their face would be price…
Sometimes "now with added GPU" is not the issue at all. There's a demo program that comes with libcaca, called cacademo. It can either output text to standard output with ECMA-48 control sequences, or crank up a built-in X client that displays a very simple text window. I SSHed into a remote machine with it from a local machine that had an X server. Tunnelled over the SSH connection, the X version of the demo was a l…
As someone who still just uses whatever terminal emulator my desktop environment provides, what are the advantages of choosing another terminal emulator application? Also, what's the point of providing GPU rendering on the terminal? I've never experienced latency or any problems otherwise related to rendering, so I wonder why some terminals nowadays pride themselves in using GPU rendering. Am I missing something? Als…
My question is what's their selling point, I used the past few years few terminals that have pretty good features: - Alacritty minimal and blazingly fast - Wezterm with batteries included - Warp even batteries included
Kitty has the lowest latency and is the best terminal in the market, but they are not on windows.
I'd love some sixel support to embedded graphics in the terminal
Or some terminal graphics protocol, which is more efficient than sixels: https://sw.kovidgoyal.net/kitty/graphics-protocol/
Sometimes "now with added GPU" is not the issue at all. There's a demo program that comes with libcaca, called cacademo. It can either output text to standard output with ECMA-48 control sequences, or crank up a built-in X client that displays a very simple text window. I SSHed into a remote machine with it from a local machine that had an X server. Tunnelled over the SSH connection, the X version of the demo was a l…
Did you try ssh compression to see if it made any difference?
I think that part of the problem lies with SSH: the lack of batching as I mentioned, which might also be at ncurses' door too. Of course one wants terminal output to go over the wire as soon as possible, and not wait "until we have a buffer-ful". But not in this case.
Rather, batching up the control sequences to change colour, cursor position, and then output the relevant character into a single exchange over the wire would be better. That would be equivalent to a an X primitive to write character X at position Y with attributes Z, which presumably goes as a single message over the wire.
But a combination of whatever output buffering ncurses and libcaca are doing, what happens in the pseudo-terminal and sshd at the remote end, and then what happens at the local end when ssh is outputting to its pseudo-terminal, are all almost certainly strongly militating against that.
... In addition to converting lots of numbers from machine-readable to human-readable, then back to machine-readable again. (-:
I should mention that at one point I was transcoding from AIXTerm to ITU T.416 colour control sequences. The latter are about 4 times as long as the former, and that noticeably slowed things down even further. Yes, I'm in favour of 24-bit colour like the other terminal emulator authors, but it does come at a measurable price.
As someone who still just uses whatever terminal emulator my desktop environment provides, what are the advantages of choosing another terminal emulator application? Also, what's the point of providing GPU rendering on the terminal? I've never experienced latency or any problems otherwise related to rendering, so I wonder why some terminals nowadays pride themselves in using GPU rendering. Am I missing something? Als…
I have news for whoever did that screen shot: 256 colours is not "all colours" nowadays. (-: There was a real push, which must be approaching a decade ago at this point, to get all terminal emulators able to understand the ITU-T T.416 control sequences for direct 24-bit RGB colour. Even if they implement it really badly , and some do, almost everyone tries to support this colour system now. See the screenshot of the…
Apple didn’t get the memo it seems. Terminal.app has been unchanged in many, many years. I still stubbornly use it as my daily driver for some probably terrible reason.
As someone who still just uses whatever terminal emulator my desktop environment provides, what are the advantages of choosing another terminal emulator application? Also, what's the point of providing GPU rendering on the terminal? I've never experienced latency or any problems otherwise related to rendering, so I wonder why some terminals nowadays pride themselves in using GPU rendering. Am I missing something? Als…
https://github.com/microsoft/terminal/issues/10362
It really highlighted how crappy software gets written in large corporations. They told him rendering monospaced fonts on the GPU would involve a multi year PHD research project.
Apparently they then went on to infiltrate his discord server so they could ask questions. Then write up a blog post calling the change "trivial".
My question is what's their selling point, I used the past few years few terminals that have pretty good features: - Alacritty minimal and blazingly fast - Wezterm with batteries included - Warp even batteries included
Kitty has the lowest latency and is the best terminal in the market, but they are not on windows.
It's really a shame that more terminals don't support this protocol, because we could have a lot more sophisticated terminal applications.