Terminal.app is very slow with Pragmata fonts #76
Comments
|
I can confirm that PragmataPro slows down the frame rate of scrolling. In my case it helped to use the PragmataPro Mono without ligatures. |
|
Thanks @Tekl and @cedeber to let me know it. I'm almost sure that this is caused by the high number of glyphs of PragmataPro (9000 vs. ≈300 of the usual monospaced). The solution is to create a light weight version with ligatures. To do this I need to know which are the essential Unicode sets for you. Could you help me in this choice? |
|
I have exactly the same issue. Especially the apps using ncurses library are extremely slow. To answer your question, I can not speak for everyone of course, but for me it would be acceptable if light version will include Basic Latin, Latin-1 Supplement, Latin Extended-A, Cyrillic and Box Drawing. |
|
Can confirm, the slowdown is even more noticable when inside tmux. |
|
I use tmux as well and it's absolutely unusable with PragmataPro in Terminal.app. PragmataPro Essential works fine. @fabrizioschiavi I think if you were to make a subset similar to Fura Code Powerline (basically, FiraCode with Nerd Fonts -- https://github.com/ryanoasis/nerd-fonts/tree/master/patched-fonts/FiraCode) that it work better. I've been using Fura Code without problems for a while now. |
|
I've also noticed that it's really slow in |
|
Like @Tekl I noticed that using PragmataPro Mono without ligatures is much faster than using the other variants. |
|
Same case for me. I notice that iTerm handles it a bit better, but can still feel a lag comparing with other fonts like SF Mono. Even with PragmataPro Mono without ligatures, when scrolling fast (for example compiling with tons output lines or keep scrolling a large text file), the slow/lag appears. A PragmataPro lite would a great idea! |
|
fwiw I've switched to alacritty which is super fast. It doesn't support ligatures but PragmataPro is great even without them. |
|
I decided to release a new Essential PragmataPro version in order to fix this issue. |
|
After Alacritty I've tried Kitty and settled with it — it supports ligatures and performs very well even with such big fonts as PragmataPro. Screenshot: |
|
I can confirm Kitty is super fast with PP. MacVim chokes on the number of glyphs I believe (even without ligatures, but especially with ligatures). |
|
My 2 cents as I would love to see this fixed too. Within Blink PP flies, but the liga is definitely slower. In our case you only notice it when loading or resizing, scroll is ok and cat large files is good too, but if you are used to the non-liga will notice the difference. Just filled out the survey, but let me know if you would like us to help you test anything, we may have better control of the rendering. |
|
Thanks friends! |
|
Make simpler fonts? |
|
I don’t think that the number of characters is to blame. Have you tried to remove all OpenType features? Then add them piece by piece and see then it becomes slow again. |
|
Good suggestion! Thanks Georg! |
|
I, too, can vouch for Kitty with Pragmata Pro - works great! @andreypopp off-topic, but what nvim theme are you using? Although I've always preferred a dark theme, your screenshot has intrigued me. It looks super clean with Pragmata Pro and its lovely bold font. |
|
Having the same issue here, Terminal.app is unusable. |
|
I too have the problem with the |
|
@LettError I just tried to remove 4000 glyphs but nothing changed. I suspect that the number of glyphs aren’t the cause. Probably some hide and untouchable glyph for Terminal? |
|
¯\_(ツ)_/¯
Erik
… On 16 Jul 2018, at 09:34, Fabrizio Schiavi ***@***.***> wrote:
@LettError I just tried to remove 4000 glyphs but nothing changed. I suspect that the number of glyphs aren’t the cause. Probably some hide and untouchable glyph for Terminal?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@fabrizioschiavi I noticed something recently. FYI, macOS Mojave might not have subpixel rendering anymore. |
|
Hello everybody, I'm helping out @fabrizioschiavi with profiling and optimisations for the upcoming version of This would be of immense help! k. |
|
Hi. I notice no differences with or without subpixel optimization. I did a copy of the default "Pro" theme and changed the font to Pragmata. I am using macOS 10.13.6 on a MacBook Pro 13" end 2013. The performance issue is visible after a few |
|
Hi @cedeber, |
|
What I do in cases like this is to remove stuff from the font until the issue is fixed. Then add different pieces back to see when the issue reappears. So:
And so on. That way I usually have the culprit in 10-20 min. |
|
@schriftgestalt Thanks — that's pretty much exactly what we've done here so far. This is called binary search, and it is known to work really well :) The problem is that Terminal.app is producing absolutely disastrous results for some people, and the lucky ones can hardly reproduce anything at all. |
|
@carloscabanero It all depends on the specific strategy of glyph atlas maintenance. I can easily imagine there is someone out there re-rasterizing ALL glyphs in the font at once, which is what they probably consider good enough for "most fonts out there" (although I'm really hoping nobody is doing something like that). But regardless, Pragmata Pro is a clear edge case, and it tests the limits of most editors and terminal emulators it is used with like nothing else. |
|
I just had a crazy idea and thought about why not test This is the console log:
I don't know if it can help, I don't find any logic here except the amount of space char 🤔 |
|
@cedeber Totally agree, there is no rhyme or reason to any of this :) I am also getting very bizarre behaviour (see 🍺report above). However, looking at your scroll buffer... Could you do me a favour and temporarily kill your $PS1 provider script, then restart Terminal and test from scratch? I get a feeling Terminal chokes on non-BMP code points. |
|
So basically these are not your friends:
|
|
@carloscabanero Staying on the subject of terminal emulators, here's a good example what not to do in terms of GPU-side glyph cache management. Although it is designed to make an optical appearance of instant font resizing, Pragmata Pro is the ideal litmus paper to test some interesting assumptions people make when they think about typefaces. Try pasting I guess my point is that it is not always immediately clear what exactly goes "nuts" — the font, or the software that is trying to put it on screen. In case of Terminal.app it is clearly the latter. Not sure about Blink, but happy to discuss. To the next aspiring engineer working on the next VT100 emulator, I highly recommend using only Pragmata font during the development — not only for his code editor, but also for testing the software :) |
|
@kelas the squares render correctly on the term, it’s a big fat right arrow. I guess it’s simply not in the monospace font the browser uses. |
|
@kelas I can speak for Blink. We are a heavily modified HTerm and use WebKit for this calculation. It is possible that this is not a very optimized path within the rendering engine, but at the same time it is a very specific gesture (pinch to zoom) that “feels” slow just because you are used to a smoother experience. Not a gigantic deal and no one complained, but I feel it. That’s why I was curious to know if there may be something else to be optimized on either side. Because whatever calculations take place, they only take this long with Pragmata. |
|
@cedeber Please |
|
I think I just figured what makes Terminal.app slow for me. It's colors! I set my prompt to have blue color so that I can distinguish it easier from the output and it makes the Terminal.app crawl. This reproduces it for me: #!/bin/sh
BLUE="$(tput setaf 27)"
RESET="$(tput sgr0)"
for i in `seq 1 100`; do
echo "${BLUE}>${RESET} $i"
done |
|
@dop bravo, this connects. I get the same. |
|
@dop And now the fun part. if you disable ANSI colors and anti-aliasing in the profile, what do you get? :) |
|
It still scrolls terribly slow. Is that expected? |
|
None of this is expected. No wonder this went uncaught for so long. It is not just colors, it is specific sequences! This kills the scroll: #!/bin/sh
BLUE="$(tput setaf 27)"
RESET="$(tput sgr0)"
for i in `seq 1 100`; do
echo "1${BLUE}0${RESET}"
doneAnd this doesn't: #!/bin/sh
BLUE="$(tput setaf 27)"
RESET="$(tput sgr0)"
for i in `seq 1 100`; do
echo "${BLUE}10${RESET}"
doneBut anyway — we finally have a reproducible case, and can apply divide and conquer as @schriftgestalt suggests. @dop very nice catch, amazing intuition. |
|
Happy to let everyone know that the issue is finally isolated. Those who think Terminal.app is still a good idea in A.D. 2018, expect good news soon :) |
|
I pinged a contact at Apple and he told me that you should file a bug. If you do, post the radar number that I can send it to him. |
|
@schriftgestalt The horrors I have seen in the past few hours looking at Terminal's process stack samples trying to understand what is it burning 100% CPU on while scrolling a trivial terminal window set in Pragmata or Iosevka, make me think Terminal authors are the last people I wanna deal with :) Hope they are still around, because the software looks a bit summer 2000. The issue seems pretty clear, Terminal is badly confused by the fact that Pragmata is not monospaced and has additional substitution features. Still have to discuss with @fabrizioschiavi, but I think there is a relatively painless solution. @dop 's amazing insight came right on time :) And thank you! |
|
@carloscabanero sorry for the wait. I'm Blink's paying customer for a while now, always thought mosh was a strong idea, but I've been out of touch with mobile terminals lately. So basically I understand you're having issues achieving a responsive zoom of a text viewport set in PPro. As you figured, I've seen plenty of this lovely font lately, including some major performance bottlenecks in a scenario similar to yours — only the surface had a bit more pixels and the target frame rate was a bit higher. Responsiveness is never easy, but there is always a hack which is sometimes hard to spot. And it is never the font's fault, I realized :) You're not necessarily completely bound by Webkit's text layout performance, and what you're seeing with Pragmata could be a hint at a more general potential improvement. |
|
But as you have a proper test case, filing a bug is easy. And it might actually get fixed. |
|
@carloscabanero Only when everything else fails trying to achieve something truly responsive, people finally quit trying to make sense of countless Apple's deprecated APIs and remember that SGI gave us OpenGL sometime around mid 90's. Sublime Text, for example, had a major difficulty keeping their viewport responsive when Retina popped out, so pretty much the only thing you see these days when you scroll a document in Sublime Text on a Mac is an OpenGL front buffer (although not without some non-portable, poorly documented |
|
@schriftgestalt It is all up to @fabrizioschiavi anyway. I only drive the bus :) |
|
Why am I seeing random/weird colors?
|
I might add that in case of colour output Sorry about the spam, but all of this just might save someone a lot of time. We get to suffer, but the next guy doesn't have to. |
|
@dop Building on your idea, here is a fun way to benchpress a terminal emulator with a given font: curl -OJ https://github.com/haasn/interpolation-samples/raw/master/60fps/native.mkv
TERM=ansi
HD="--vo-tct-width=96 --vo-tct-height=54"
PLAY="mpv --vo tct --vo-tct-256=yes --vo-tct-algo=plain"
$PLAY $HD native.mkv
$PLAY $HD native.mkv > stream.txt
cat stream.txtThe above is best enjoyed at silky 60fps in iTerm2 and snappy 2000fps in Alacritty. Back at Terminal.app, we take comfort in counting dropped frames and drawing comparisons:
On a more serious note, a modified version of @dop's script can be used to show that any font, ligature or not, monospaced or not, can render Terminal.app unusable. At 10pt in a 134x45 window running on macOS Mojave, the output of the following script causes completely substandard latency with Fira Code, Hasklig, Iosevka and Menlo. @fabrizioschiavi I now agree with @schriftgestalt this should be reported as defect. A modern terminal emulator doesn't have to be this slow, really. #!/bin/sh
TERM=ansi
bold=$(tput bold)
r=$(tput setaf 1)
g=$(tput setaf 2)
b=$(tput setaf 4)
R=$bold$r
G=$bold$g
B=$bold$b
X=$(tput sgr0)
# disable colors
#unset r g b R G B X bold
# ppro, iosevka, fira
L1="->"; L2="<-"; L3="!=" ; L4="0>="; L5="1<="; L6="2=="
t="${r}R${X}${g}G${X}${b}B${X}${r}${L1}${X}${g}${L2}${X}${b}${L3}${X}${r}${L4}${X}${g}${L5}${X}${b}${L6}${X}"
T="${R}R${X}${G}G${X}${B}B${X}${R}${L1}${X}${G}${L2}${X}${B}${L3}${X}${R}${L4}${X}${G}${L5}${X}${B}${L6}${X}"
for i in `seq 1 500000`; do
echo "$i $T$t$T$t$T$t$T"
done
#//:~To measure raw terminal sink speed without the overhead of $ ./nuketty.sh > payload.txt
$ time cat payload.txt
These timings are not useful for any precise calculations — it is easy to see that under high bitrate Terminal.app drops to a lower FPS and begins to skip large chunks of input stream. As there seem to be some hardcoded limits to that (I'm guessing 5000 lines/2 FPS), time-per-frame eventually begins to impact stream processing speed; in turn, characteristics of the font affect time-per-frame, so, all other things being equal, total time is a useful measure of the font's relative performance in Terminal.app. By itself, adaptive frame rate is a perfectly valid way to save a lot of CPU cycles and make non-interactive streams ( Back at Terminal.app, adaptive frame rate heroics no longer help when the user starts to scroll the buffer using a precision HID such as Apple trackpad. In that case, poor time-per-frame can no longer be swept under the rug as it becomes an integral part of sensory feedback loop. Human brain, as slow as it is, easily picks up latencies above 15ms, and is not easily fooled — normally you simply have to render fast enough to provide feedback before 15ms deadline. With that in mind, a few seconds of difference on 500,000 lines of synthetic input might still not seem like a big deal, but when 0.827 comes out I strongly recommend to try this benchmark with Terminal.app and compare your personal scrolling experience using different fonts. Be ready for surprises. What is really amusing about benchmarking Terminal.app this way (attn @carloscabanero) is that disabling ligatures actually results in measurably worse performance. The only explanation I can think of is that because we have twice as many glyphs to be rendered and UTF-16-encoded In reality, complex contextual substitution will surely slow things down, although the relative impact on the overall text layout performance is clearly not what is commonly believed. On the other hand, it is perfectly possible (and very easy!) to produce a substitution table that will utterly crush user experience — that's why, as with any software, profiling and regression testing of OpenType features on carefully chosen test data is absolutely essential. @schriftgestalt Your articles are awesome. Thinking out loud, there is absolutely no shortage of OT syntax manuals in the wild, but it proves to be impossible for a newcomer like me to find a single public resource about the actual design of substitution tables. Given that some of these state machines are designed by people who have little clue what an FSM is, it really seems the world could use a good read on this — most importantly, the basic pitfalls to be avoided. Although it could be true that the vast majority of all CPU cycles in the Universe are spent on rendering OpenType text, it is not immediately clear how much of those are spent on meaningful work :) |
|
|
|
With the great help of @kelas PragmataPro is now one of the quickest typefaces in absolute. |
|
@fabrizioschiavi Hi, did you update the fonts on MyFonts? I don't see any updates. Thanks |
|
It works like a charm. Thanks a lot 🤘 |
Both of Pragmata (normal and mono) make Terminal.app very slow on macOS. Everything runs perfectly with SF Mono for instance, so it doesn't look like that it is a generic performance problem (I reset the Terminal to be sure)
Strangely, PragmataPro Mono Bold is not affected and the Terminal runs smoothly.
The text was updated successfully, but these errors were encountered: