w23 / alacritty Goto Github PK

How to reproduce:

• set background color to something bright (e.g. 808080)
• render some emojis: 🤣🙂🤪🤨🧐🤓🥰

Why: we don't have a proper alpha value for non-colored glyphs. They are uploaded from RGB source with alpha being force set to 1. So the shader only blends based on rgb values, not alpha.

How to fix, variants:

1. Can we make non-colored also rendered with proper alpha channel?
2. When uploading non-colored, generate proper alpha values
3. Have a separate RGBA atlas for colored glyphs

We either need to split wide into 2+ grid entries into atlas, or have separate "wide" lines in atlas, or use a completely separate atlas texture.

subj

They definitely should not render correctly under the new render, but we need to have examples to be able to fix.

If too many different glyphs are rendered during alacritty lifetime, they may overflow the one and only atlas supported in the new naive renderer.

Many possible things to do:

• make atlas bigger based on GL caps
• support more than one active atlas (how many: based on max bound textures GL caps). GlyphRef pixel can store a reference to a particular atlas.
• regenerate atlas(es?) on overflow, thus automatically discarding unused glyphs
• multipass rendering: draw screen quad multiple times, each time only painting glyphs from bound texture atlas.

If you increase font size with ctrl + to some big value, the cursor will completely disappear and there won't be a way to get it back with decreasing the font size again.

On Windows w/ hidpi u_cell_dim can end up being not integer, thus breaking pixel alignment in shader.

Glyphs come with weird (in a monospace context) metrics, so parts of them are outside of their designated grid cell.
What we could do:

• grid atlas can store glyphs in larger cells than display cells
• screen shader can sample neighbour cells and draw overlapping pixels too

This is due to the fixed render order: quads are rendered after grid, and render timer is a part of grid. But render timer is generated only after all regular cells are updated and quad list is already updated.

There's no easy fix:

• changing render order is infeasible. Grid passes draw background.
• adding a separate pass just for render timer is weird
• clipping cells that fall within debug timer is also weird, and might also have small perf impact given the idiosyncratic mechanism of how internal cells are passed to the rendering

Fix grid pass renderer, it will still try to render all passes even if they're empty
Check that quad renderer will also exit early

Glyphs that are larger than atlas cell end up corrupting nearby glyphs in the atlas. Oh what to do

• detect such glyphs and don't put them into grid atlas at all. let them be handles in quad atlas

It used to be drawn using rects, but now the order has changed and it has to be grid bg color

Certain monospace fonts are using non-monospace chars for certain fancy glyphs. The relevant font is font awesome or anything from https://github.com/ryanoasis/nerd-fonts/releases (there's just a bunch of ttf files, you may use whatever you want from there). The font should be without Mono in a name if you decide to use a font from a nerd fonts. Example of a font if you decide to use Fira Code from that link is Fura Code Regular Nerd Font Complete.otf, it's a monospace font but has a those custom glyphs are non monospace.

Example of such weird glyphs.         .

Really noticeable when scrolling through the entire unicode symbols file https://github.com/chrisduerr/vtebench/blob/rewrite/benchmarks/unicode/symbols

Alacritty supports transparency (config: background_opacity). It works by outputting alpha value of the final pixel
Currently the new render just writes 1.0. We should find out the correct value to write.

It's commented out for now, because the place where it's called doesn't yet know about grid size, which is essential for grid atlas

It's been noticed that sometimes glyphs reference the wrong atlas cells. No stable reproduction method known (alsamixer + change font size?)

Why:

• atlas/cache are borked?
• glyph ref cell coordinates lack precision? get out of bounds (255)?

Most common glyphs have known range: it's 7-bit ASCII. We can just index a pre-allocated array with them directly and be like super fast.

Other glyphs can go through whatever hash or not. Needs investigation and profiling.

(profile this first, maybe it's completely unnoticeable in release builds; it certainly is in debug)

Rect-based rendering (strikeout, underline, zalgo) is slightly misaligned wrt alacritty 0.4

• check w/ 0.5.0 or latest master
• redo coord transformation to be u16 pixel-based

Especially vertical. Need to figure out correct overflow metrics.
And also provide per-cell bits on which overflow directions to check (optimization -- don't check multiple neighbours if not necessary)

Some characters have double width, e.g. CJK (example string: こんにちは).
New naive simple renderer chokes on them:

• atlas gets corrupted: these chars overwrite neighbour cells
• they are rendered with incorrect positions

Two options:

• separate atlas for wide chars
• split each wide glyph into two atlas cells

Currently simple renderer forces full screen text rendering when with_api returns. However, display.rs calls with_api many times for various things like message overlays, etc. This makes it render text more than once and actively interferes with rects rendering (they get overwritten).

For example the sequence could be:

1. Clear with background color
2. Fill internal render buffers with actual terminal text data. Don't render anything yet.
3. Add "overlay" text to render buffers: messages, debug timers, etc. Don't add any background color rects, do this with text background color property instead.
4. Paint entire screen with basic text. This will paint both content and messages
5. Draw rects that do undreline/strike. Don't draw any message background rects at all.
6. Swap buffers

Alternatively, text rendering could be organized as "Draw this text into this quad", so that we could draw different parts of screen with different rects in any order we want:

• one text-renderer instance for main content
• second is for messages and stuff

That's because we render them using rects which are not aware of cursor at all.
Figure out what to do.

It runs on RPi4 (see https://github.com/w23/alacritty/tree/raspberry), but that's because it has OpenGL ES 3.
It doesn't really need one at all though. We can definitely tweak shaders to make it run on OpenGL ES 2 w/o any extensions.
This will make it run on any Raspberry device.

In old render diacritics are supported naturally: they are rendered as separate quads as everything else.
Simple render is monospace cell-oriented, so anything beyond one cell one glyph is difficult.

Proposed solution: just render diacritics using quads from a separate atlas, similar to old render. It is expected that in normal circumstances there shouldn't be a lot of them anyway.
We can use GLES2-level features for generating just a simple VBO with relevant attributes.

glTexSubImage2D call is expensive. No need to upload each glyph individually.
We can store them in a temporary buffer and commit to texture/video memory just once per frame before drawing.

Although we co precompute max glyph size for most common chars in atlas on init, we can still fail to anticipate later glyphs being even larger than that (regular glyphs even, not wide; wide should be handled separately).

Possible layered approach:

• add guard padding (a few % or pixels) to the max encountered size; can waste atlas space unneccessarily
• if we see a glyph that is larger than expected, we should invoke clear and regen for the atlas. This will invalidate all previously updated cells, so we should be careful to work around that (call for total recompute? 2nd atlas? what if it also need invalidation? recompute next frame?).

The dynamic padding around the window is transparent, since the gl:Clear is called with 0 alpha afaics, so it should be called with a proper background color and alpha. You may also do that in shader, but since clear is called also during display init, you should do it there as well(it'll be noticeable on X11 if you don't do that in clear during init).