Latest Kitty terminal release features SRGB correct linear gamma blending
github.com
github.com
When we think about AA, it is a representation of sub pixel occlusion. As such, using uniform tristimulus to sample the “in between” value is incorrect.
There is simply no “correct” approach because there are no known models that properly model visual cognition.
What we can say though, is that the intermediate subpixel should not sample RGB tristimulus, but a loose nonuniform representation that approximates the lower order visual signal representation.
When discarding signal, RGB tristimulus is more “correct”. When interpolating the signal, approximate lightness is more “correct”. Some solid analysis is available here: https://hhoppe.com/filtering.pdf
Screenshots and screen recordings of subpixel AA content is foo without magic to get clients to disable such rendition during capture...
Only if you insist in blurry fonts. Rendering sharp bitmap fonts is trivial. With the microscopic pixels that we have nowadays, bitmap fonts have more sense than ever. Too bad there is not a lot of variety in bitmap fonts of huge pixel size.
I'm typing this on a 24" 4K screen, using normal fonts and they are very sharp. I do use sub-pixel rendering and don't have any issue even with light text on dark background (Using Linux X11 with fontconfig 2.14.2).
However, the issue is that as soon as you leave high-end laptops, you actually rarely have "microscopic pixels". Most "business" screens are still a blurry mess with 1920x1080 24" panels. 32" 4k panels are serviceable (light text on dark background can get rainbowy), but you better not look at them from too close. 8k panels are still very expensive, at least in Western Europe.
For these screens, I've found that bitmap fonts are the best. They're the only way to have really crisp text, and not some rainbowy-mess. And don't get me started on the fashion trend of skinny light fonts on dark backgrounds.
What? I have had the complete opposite experience. High-end laptops (like, the ones that have multiple GPUs, or portable workstations, or gaming laptops, or etc.) tend to have utterly terrible displays, whereas cheap ultrabooks and chromebooks are the ones that get the 4K treatment. Maybe different allocation of cost?
I was thinking about macbooks and the likes of Dell XPS and Lenovo X1. I was referring to them as "high-end" since models with 4k screens tend to cost more than your "regular" enterprise-issue laptops, which usually have atrocious screens. The only laptops with HIDPI screens under 2000 € I can think of are the base Mx macbook airs. Since there are many "workable" (from a performance standpoint) models under 2000 € [0], I consider anything above "high end".
I was even eyeing some Dell Latitude and Lenovo P a year or so ago (can't remember the exact model), which I would qualify as "portable workstations", since they had 4 DIMM slots, 3 or 4 NVMe slots and at least one of them actually had some kind of Xeon CPU with ECC RAM. They all had options for a 4K screen. They all cost more than 4000 €. Whereas the laptops we typically get at work (HP Pro and Elite books) top out at FHD, and usually are quite dim and sometimes don't even have 8 bit panels.
---
[0] My current laptop is an EliteBook 845 G8. The laptop itself was around 1500 €, and upgraded to 64 GB of RAM and a Samsung 980 Pro, came in around 1800-1900 €. Aside from the absurdly bad screen, it's a laptop that is powerful enough for my needs.
Yeah, those are not high-end laptops; they are premium laptops. Important distinction—premium means price, while high-end means performance.
> The only laptops with HIDPI screens under 2000 € I can think of are the base Mx macbook airs
my own laptop (ROG Zephyrus M15) was around $1300. I regret buying it though, because it sucks terribly, but at least it has a 4K screen.
4K Chromebooks can be had for under $1000 and even as low as $750 in some cases. The ultrabooks (non-ChromeOS) can get even cheaper, but tend to hover around that price range.
https://github.com/majutsushi/urxvt-font-size
https://wiki.archlinux.org/title/rxvt-unicode#Changing_font_...
I still remember how essentially nothing happened in the terminal world from the late 90s until a few years ago (other than iTerm2 on macOS), and suddenly we have Kitty, Alacritty, Foot, and Wezterm, each developed independently of the others, and each of them better than anything that came before. It's amazing to watch these projects evolve.
I find XTerm (in Linux) and Terminal.app (in macOS) much snappier.
These measurements seem to agree with my subjective perception: https://danluu.com/term-latency
showing kitty has the same latency as terminal.app on macos.
XTerm is X11 only. Considering that Wayland is much more lightweight than X11, it's hard to imagine XTerm beating e.g. Foot, which is purpose-built for modern Wayland desktops, with almost no abstraction in between.
Not to mention that these terminals have much better overall engineering than XTerm, whose README famously states "This is undoubtedly the most ugly program in the distribution." That line alone is enough for me to avoid XTerm like the plague.
That's irrelevant. More relevant is that Wayland is adamant about presenting "perfect frames" (ie no frame tearing), which requires a sync/checkpoint for everything that's displaying, which inherently puts a lower bound on latency that non-sync-respecting X11 isn't subject to.
Also, every pixel has a "checkpoint" sampled at the display refresh rate. With tearing, the checkpoint of a pixel differs from its neighbors, with each subsequent pixel (leading to rolling shutter artifacts), whereas without, all pixels show the same sample.
At the cost of glitches, tearing and higher render load let's you put slightly newer data in the bottom third or quarter of your screen.
Not really something to write home about, especially considering that X11-users commonly run external compositors exactly to get that tear-free behavior.
I can open vim, irssi, moc, htop, nethack, or a dozen other TUI apps, and every one of them has different key bindings, different color scheme (sometimes assuming/hardcoding white text on dark background, sometimes vice versa), different paradigm for supporting multiple buffers, different way to configure it, different way to exit - but each window still has the same icon in the task bar. KDE did this better in 1996. Mac did this better in 1984.
Even if I stick 100% to using CLI (stdio) programs, the facilities have barely improved at all since the time job control was introduced - there's a lot of potential to actually innovate here, but that would probably require breaking out of the separate terminal+shell paradigm. There were more radical attempts, but AFAICT the bleeding edge of innovation in mainstream emulators is iTerm displaying the process tree in a popup.
It's the most rich ecosystem of lowest common denominator software in existence. We have sRGB correct linear gamma blending, but Emacs in terminal still loads the wrong dark/light theme - unless you cobble together a hundred lines of custom elisp glue. I don't even understand why we need gamma blending, nobody can implement an actual production-quality graphics editor in a terminal (unless you want to double down on sixels...).
Luckily it looks like wezterm will have support eventually.
So very on brand for him.
Why people keep investing themselves into Goyal's one-man-fiefdom projects is a mystery to me. I haven't used kitty, but I absolutely loathe Calibre more than any other software I use. The man couldn't design a user interface to save his life, common functions nearly everyone wants are time-consuming to set up, and the fact that calibre-web is better in every possible way speaks volumes. It took me years to realize that calibre-web had nothing to do with him, otherwise I would have switched much sooner.
I don't know anything about the drama you mention. I just know kitty is a fine terminal emulator I use all the time (also with tmux/byobu) and I am thankful the author created it. Calibre I also use from time to time and it works for my purpose. I am happy it exists and I can just shovel my ebooks onto my kindle.
It sounds like you used Calibre for years but still complain about it even though it's free..
He also accepts lots of PRs from contributers. Once you do this, it is no longer your project only.
An example PR (there are a few others equally concerning): https://github.com/kovidgoyal/kitty/pull/3544
I don't want to defend phone-home mechanisms because I am personally not a fan but an update check really is different from surveillance. I in general agree with the comment that the feature should be opt-in but the argument was not presented in a good way.
>For syncing reading progress across devices KOReader is apparently the way to go. You can setup syncing on there and any device that has KOReader installed will have the same reading position.
From google.
+ OPDS support regardless of device
Calibre has saved my bacon countless of times. It's absolutely crazy how many crappily formatted epubs are out there (not pirated ones, mind you, but bought from stores). Without Calibre to clean these up, my reading experience would have been so much worse.
You gain some, you lose some. Kitty is really low-latency and renders most Unicode shenanigans correctly (the main exception being RTL text). I can live with the fact that I don't get a normal menu bar on Wayland then :-)
Even if you open a pull request for this, that is asking the maintainer their many many hours of future maintenance and support they have to do to keep this feature alive and improved, all for free.
Goyal is opinionated but so what? you are free to not use his free software...or you could fork it
I actually find his sass amusing...
That's exactly what they're doing, what are you talking about?
I want to go 100% kitty (both locally and via SSH), but I don't know whether it can persist sessions. With tmux I can kill the Kitty app, and when I reopen it, all tabs are there, and any running processes keep running in the background (especially important for SSH).
Is kitty able to do something like that?
That's something I learned digging through kitty's github issues when doing a deep dive looking for a term that runs on Linux and supports tmux control mode.
This turned me off from using it as someone who needs tmux daily and I wanted to share that information so that others like me might save some time investigating.
In plain English, can someone explain what's going on, and why anyone should care?
This patch corrects that, and adds some contrast controls since few people would prefer the 100% physically correct blending (I'd assume fonts are not designed for that in the first place, so the alpha value coming out of the subpixel calculation isn't really optimal). This brings it closer to macOS' Terminal.app.