101–110 of 128 posts
Earlier quoted context omitted.
> until you accidentally unleash a lot of output at once The only time this happens, is when I do something wrong, like `cat`-ing the 12MB binary instead of the config.json, or `tail -f` into the output device of the core logging endpoint and forget to pipe into `grep`. If that happens, I usually terminate the process anyway.
This is also pretty common when running test runners a lot
Earlier quoted context omitted.
Before you press Ctrl+C and type the correct command, your neighbour running Kitty has already got the last line of the output (which is often the only thing that one really needs). I switched to Kitty because I felt that the increased speed produced a perceived improvement in my workflow.
>which is often the only thing that one really needs) tail 1_gb_of.txt ...will get the last line of output long before the rendering engine finished initializing. And it will probably do so even on a 10year old laptop with no GPU, in virtual console, while the system is running under load ;-)
I see you posted the same comment again and again, every time asking for a possible use case, and when people provided you with theirs, you answered, «well, but I would…», with the tone of who is saying that mine is the only rightful way to do it.
Well, it's not.
Earlier quoted context omitted.
Is it more complicated than wanting to update the display as often as its fresh frequency? Faster screen updates, lower CPU & power usage. You might not notice the difference until you accidentally unleash a lot of output at once - then you'll see the difference. Some terminals start to update infrequently to save themselves, some hang completely while burning the CPU. Psychologically I feel more in control of my com…
> until you accidentally unleash a lot of output at once The only time this happens, is when I do something wrong, like `cat`-ing the 12MB binary instead of the config.json, or `tail -f` into the output device of the core logging endpoint and forget to pipe into `grep`. If that happens, I usually terminate the process anyway.
Earlier quoted context omitted.
When you don't actually realise it is 1 GB before you cat it.
So then I hit Ctrl-C and issue the correct command. How does a GPU based renderer improve on that use-case?
Earlier quoted context omitted.
>which is often the only thing that one really needs) tail 1_gb_of.txt ...will get the last line of output long before the rendering engine finished initializing. And it will probably do so even on a 10year old laptop with no GPU, in virtual console, while the system is running under load ;-)
As other said, sometimes you do not know that there is going to be a lot of output. In my case, I often save the time it takes to press Ctrl+C and add "tail" at the beginning of the previous command I see you posted the same comment again and again, every time asking for a possible use case, and when people provided you with theirs, you answered, «well, but I would…», with the tone of who is saying that mine is the o…
Earlier quoted context omitted.
Hmm, I do wonder why would a terminal use so much GPU ressources. Maybe it gets better with reducing scrollback? Seems extreme anyway.
Caching glyphs, into a texture. Then they don't need to be re-rendered and can just be copied.
Multiply by 3 if you want to support subpixel rendered glyphs, that still leaves us with a very comfortable upper bound of 6MB.
Note that optionally you can keep the glyphs on CPU memory as opposed to GPU memory, and just push the needed data in a streaming fashion to the GPU for each frame. Since there is no texture filtering for fonts (GL_NEAREST for OpenGL), no need to create a font-atlas and no needed for complicated font atlas packing. Glyph data can be allocated in a simple 1-dimensional space, and streaming a glyph's data up is just a matter of bumping a pointer and a single memcpy.
Serious question: how much does it benefit to accelerate terminal on GPU? Is it really worth the effort?
Lots and yes. The effort has already been made, there are lots of very capable and stable GPU accelerated terminal emulators available. The speed boost makes them worth using. If you've ever accidentally returned a minified file from grep you'll know most terminal emulators grind to a halt.
This doesn't sound like a rendering issue, though.
Many text editors can't cope with extremely long lines either, terminal-based or not. That happens when they store lines as flat buffers without any algorithmic optimization.
GPU has the potential to speed up terminal rendering a little bit, but in the absence of antialiasing (cache glyphs with the right background color) you can probably achieve 60fps on a 4K screen full of glyphs. It's just memcpy(), a 4K screen is about 32MB of data. 32MB * 60 = 1.8GB, today's memory is much faster.
https://wezfurlong.org/wezterm/config/keys.html Happy to see that it includes support for clearing scroll back and that the default key binding for that is the same as it is in the Terminal.app that comes with macOS; Super + K. I just might give this Wezterm a go on my own computers. And since Wezterm is cross platform with support for all three computer platforms that I use; macOS, Linux, FreeBSD, I may finally have…
I've tried it a little bit now with a custom config, and have it almost the same way that Terminal.app is on my system now. My configuration for Wezterm at the moment: - I set the color scheme to Afterglow, which is a lot like the default color scheme of Terminal.app. - I downloaded the SF Mono font from https://developer.apple.com/fonts/ so that it is available to Wezterm, and I defined the font size to be the one t…
1. Tab titles are set using escape sequences, typically OSC 0, 1 or 2. You can find examples for configuring shells to emit those online, for example: https://superuser.com/questions/84710/window-title-in-bash Terminal.app defaults to snooping the local process list to set titles; wezterm doesn't do this as the terminal may not be local (eg: could be remote ssh or multiplexer session) and using escape sequences gives definitive control.
2. I'd love to troubleshoot this with you; please file an issue!
3. There are currently a set of open and related IME/macOS issues at the moment. You may want to try looking at https://wezfurlong.org/wezterm/config/keys.html#macos-left-a... and fiddle with those options, but you may be left disappointed until the root of those issues are resolved!
4. This is a consequence of being a cross platform program rather than a macOS-first application. There isn't a way to keep the GUI running without any Windows today. Perhaps in the future?
Any Kitty users tried this? I’ve found Kitty to be exemplary so would be curious if anyone finds this an improvement?
I found kitty faster on my system