Re: [dev] [st] wide characters getting cropped
On Thu, Nov 11, 2021 at 05:31:15PM +0100, Страхиња Радић wrote: > (for example, if a simple "cat /some/file" for a multi-line text file > has a delay anywhere from 500 ms to a second or two between the output > of individual lines, when not dependant on factors such as reading > from a network of a faulty hard disk; that would just be annoying, but > still usable). You're correct, cating some file is not something that needs critical speed. But that's not what I'm talking about when I say "latency". I'm reffering specifically to "input latency" or "end-to-end latency", which is the delay between a physical input (in this case key-press on the keyboard) and it's output (in this case the key-press being rendered). - NRK
Re: [dev] [st] wide characters getting cropped
On 21/11/10 08:55, NRK wrote: > I wouldn't say it's "critical need". And if we judge from that pov then > one could ask, "What's the critical need for a dynamic window manger or > minimal softwares in general?". Terminal emulator's job is to allow terminal input/output. Latency is simply not relevant, unless it is noticeable by a human (for example, if a simple "cat /some/file" for a multi-line text file has a delay anywhere from 500 ms to a second or two between the output of individual lines, when not dependant on factors such as reading from a network of a faulty hard disk; that would just be annoying, but still usable). st doesn't have such issues, so anyone experiencing them should look for the cause elsewhere (Xft/fontconfig?). Also, the need for "minimal software" is not comparable to the "need" for "low latency" in a terminal emulator. The former is a fundamental concept, while the latter is superficial. > XTerm has many (visible) problems. Maybe I've misconfiuged it, but I > cannot get it to fallback to other fonts reliably, and thus some glyphs > don't render. It also chokes badly when it tries to render some unicode > glyphs for the first time. If you refer to color emoji or Nerd Font symbols, they are poorly supported in X, and I'd even say they are bloat by themselves. But it is to be expected of XTerm to have problems. To quote https://st.suckless.org, > xterm is bloated and unmaintainable. Here's an excerpt from the README: > > Abandon All Hope, Ye Who Enter Here > > This is undoubtedly the most ugly program in the distribution. It was one > of the first "serious" programs ported, and still has a lot of historical > baggage. Ideally, there would be a general tty widget and then vt102 and > tek4014 subwidgets so that they could be used in other programs. We are > trying to clean things up as we go, but there is still a lot of work to > do. > > Needless to say things have not changed, it's still ugly. It has over 65K > lines of code and emulates obscure and obsolete terminals you will never need. > > The popular alternative, rxvt has only 32K lines of code. This is just too > much for something as simple as a terminal emulator; it's yet another example > of code complexity. > > Terminal emulation doesn't need to be so complex. signature.asc Description: PGP signature
Re: [dev] [st] wide characters getting cropped
On Tue, Nov 09, 2021 at 02:00:57PM +0100, Laslo Hunhold wrote: > I'm always wondering: What do you suggest to improve the > latency-situation? If I knew the answer to that, then I would've ditched XTerm and patched ST already. Unfortunately I know next to nothing when it comes to the inner workings of a terminal. On Tue, Nov 09, 2021 at 10:09:48PM +0100, Страхиња Радић wrote: > I'm wondering what's the use case for such critical need for low latency? I wouldn't say it's "critical need". And if we judge from that pov then one could ask, "What's the critical need for a dynamic window manger or minimal softwares in general?". XTerm has many (visible) problems. Maybe I've misconfiuged it, but I cannot get it to fallback to other fonts reliably, and thus some glyphs don't render. It also chokes badly when it tries to render some unicode glyphs for the first time. I have neither of those problems on ST. But those situations are far less common for me compared to situation where I'm typing into the terminal (which is always). So if I can get a better experience out of the most common workflow out of a certain software, then it's going be the one I will end up using. Also just to clarify, I wouldn't say ST has "latency issues", that implies the situation is _bad_. As I've said, it's the 2nd most responsive terminal I've tried and _MILES_ better than these "gpu accelerated" terminals. It's also the only other terminal that I still have installed in my system. - NRK
Re: [dev] [st] wide characters getting cropped
On 21/11/09 02:00, Laslo Hunhold wrote: > I'm always wondering: What do you suggest to improve the > latency-situation? Can we even be "better" than the screen's framerate? I'm wondering what's the use case for such critical need for low latency? Playing DOOM (2016) in a terminal with aalib? That's not what terminal emulators were meant for. signature.asc Description: PGP signature
Re: [dev] [st] wide characters getting cropped
On 21/10/29 12:18, Dmytro Kolomoiets wrote: > Страхиња Радић, do you have a cleaned up version of the patch > which applies to latest st tree without rejecting hunks? No, but it shouldn't be too hard to make given the PR. I have applied it to my fork of st (https://git.sr.ht/~strahinja/st). signature.asc Description: PGP signature
Re: [dev] [st] wide characters getting cropped
> https://github.com/LukeSmithxyz/st/pull/224 Страхиња Радић, do you have a cleaned up version of the patch which applies to latest st tree without rejecting hunks? On Wed, 27 Oct 2021 at 23:12, NRK wrote: > > On Wed, Oct 27, 2021 at 09:38:41AM +0200, Hiltjo Posthuma wrote: > > Its a longstanding myth st has input latency issues. > > The common quoted benchmark is wrong. > > If we're thinking about the same benchmark then it's also outdated. > But regardless I didn't base my decision on that. Sometimes ago (9-10 > months) I was testing out a whole bunch of different terminals, some of > the worst offenders when it comes to latency was Alacritty and Termite > IIRC. > > ST, in my expereince, has been the 2nd most responsive terminal and > quite close to XTerm. But still not as responsive and thus overtime I > have switched over to it. > > It would be interesting to see someone doing a proper benchmark with all > latest terminal versions, since I don't have any data to back up what I > am saying :) So take it as you may. > > - NRK >
Re: [dev] [st] wide characters getting cropped
On Wed, Oct 27, 2021 at 09:38:41AM +0200, Hiltjo Posthuma wrote: > Its a longstanding myth st has input latency issues. > The common quoted benchmark is wrong. If we're thinking about the same benchmark then it's also outdated. But regardless I didn't base my decision on that. Sometimes ago (9-10 months) I was testing out a whole bunch of different terminals, some of the worst offenders when it comes to latency was Alacritty and Termite IIRC. ST, in my expereince, has been the 2nd most responsive terminal and quite close to XTerm. But still not as responsive and thus overtime I have switched over to it. It would be interesting to see someone doing a proper benchmark with all latest terminal versions, since I don't have any data to back up what I am saying :) So take it as you may. - NRK
Re: [dev] [st] wide characters getting cropped
The benchmark was done on macOS, if I'm not mistaken
Re: [dev] [st] wide characters getting cropped
On Wed, Oct 27, 2021 at 03:52:09AM +0600, NRK wrote: > On Tue, Oct 26, 2021 at 07:51:52PM +, Ian Liu Rodrigues wrote: > > I've noticed that in some situations wide characters are being cropped > > on my terminal. The following script, which uses a wide character from > > the "Nerd Font Symbol"[1], shows a test case: > > > > > > echo -e '\e[31m \e[0m c' > > echo -e '\e[31m \e[0mc' > > > > Hi Liu, > > I remember having the same problem in ST, however it works fine now. > Looking at my git log I haven't applied any patches for it and even the > upstream branch works fine for me. > > This might be related to terminfo (5). I won't be delving any deeper > into this as I've moved over to XTerm long ago due to input latency > reasons. You might want to check FAQ provided in the ST repo. > > P.S echo is non-portable. Use printf. > https://wiki.bash-hackers.org/commands/builtin/echo#portability_considerations > > - NRK > Its a longstanding myth st has input latency issues. The common quoted benchmark is wrong. -- Kind regards, Hiltjo
Re: [dev] [st] wide characters getting cropped
On Tuesday, October 26th, 2021 at 17:27, Страхиња Радић wrote: > For me, this patch fixed the glyph truncation: > > https://github.com/LukeSmithxyz/st/pull/224 > > Perhaps someone could add this to the official patches? Thanks! I will try applying that patch.
Re: [dev] [st] wide characters getting cropped
On Tue, Oct 26, 2021 at 07:51:52PM +, Ian Liu Rodrigues wrote: > I've noticed that in some situations wide characters are being cropped > on my terminal. The following script, which uses a wide character from > the "Nerd Font Symbol"[1], shows a test case: > > > echo -e '\e[31m \e[0m c' > echo -e '\e[31m \e[0mc' > Hi Liu, I remember having the same problem in ST, however it works fine now. Looking at my git log I haven't applied any patches for it and even the upstream branch works fine for me. This might be related to terminfo (5). I won't be delving any deeper into this as I've moved over to XTerm long ago due to input latency reasons. You might want to check FAQ provided in the ST repo. P.S echo is non-portable. Use printf. https://wiki.bash-hackers.org/commands/builtin/echo#portability_considerations - NRK
[dev] [st] wide characters getting cropped
Dear all, This is my first post here after two failed attempts, I think because of the email being sent as HTML. Lets hope this one goes alright. I've noticed that in some situations wide characters are being cropped on my terminal. The following script, which uses a wide character from the "Nerd Font Symbol"[1], shows a test case: echo -e '\e[31m \e[0m c' echo -e '\e[31m \e[0mc' Here is a screenshot of the script's output: https://qu.ax/3SBs.png The only difference between the two echo's is the position where the foreground color resets: the first resets right after the wide character, whereas the second resets after the space. I've hacked a little bit in the source code but couldn't figure out how st paints the characters. I see in function xdrawglyphfontspecs[2] that it calls this: /* Clean up the region we want to draw to. */ XftDrawRect(xw.draw, bg, winx, winy, width, win.ch); which seems to clear the character rectangle unconditionally, but then shouldn't the second echo also crop? Kind regards, Ian L. Rodrigues [1]: https://raw.githubusercontent.com/ryanoasis/nerd-fonts/d0bf73a19c3459aab39734a05159e2694911d7d6/src/glyphs/Symbols-2048-em%20Nerd%20Font%20Complete.ttf [2]: https://git.suckless.org/st/file/x.c.html#l1453
Re: [dev] [st] wide characters getting cropped
n 21/10/26 07:51, Ian Liu Rodrigues wrote: > echo -e '\e[31m \e[0m c' > echo -e '\e[31m \e[0mc' > > > Here is a screenshot of the script's output: https://qu.ax/3SBs.png For me, this patch fixed the glyph truncation: https://github.com/LukeSmithxyz/st/pull/224 Perhaps someone could add this to the official patches? signature.asc Description: PGP signature
