Texture-Less Text Rendering

I've never been able to make text look good at small sizes whenever I've tried immediate mode text rendering. Even in the first shadertoy, in vec2(30, -30), if you change 30 to 300, you'll see some artifacts. Is there a trick to getting that right? For me, multisampling the texture inside fragment shader appears to work the best, although it still isn't as good as the state of the art.

offtopic but interesting, matrix effect in HTML/CSS/JS, 1024 bytes,

``` <head><style>{margin:0;padding:0;line-height:1;overflow:hidden;}div{width:1em;position:absolute;}</style><script> w=window;n=w.innerWidth;m=w.innerHeight;d=document;q="px";function z(a,b){return Math.floor(Math.random()(b-a)+a)}f=" 0123456789";for(i=0;i<45;i++)f+=String.fromCharCode(i+65393);function g(){for(i=0;i<90;i++){r=d.createElement("div");for(j=z(20,50);j;j--){x=d.createElement("pre");y=d.createTextNode(f[z(0,56)]);x.appendChild(y);x.style.opacity=0;r.appendChild(x)}r.id="r"+i;r.t=z(-99,0);with(r.style){left=z(0,n)+q;top=z(-m,0)+q;fontSize=z(10,25)+q}d.body.appendChild(r);setInterval("u("+i+")",z(60,120))}}function u(j){e=d.getElementById("r"+j);c=e.childNodes;t=e.t+1;if((v=t-c.length-50)>0){if((e.style.opacity=1-v/32)==0){for(f in c)if(c[f].style)c[f].style.opacity=0;with(e.style){left=z(0,n)+q;top=z(-m/2,m/2)+q;opacity=1}t=-50}}e.t=t;if(t<0||t>c.length+12)return;for(f=t;f&&f>t-12;f--){s=1-(t-f)/16;if(f<c.length&&c[f].style){c[f].style.opacity=s;}}} </script><body text=#0f0 bgcolor=#000 onload=g()> ```

https://codegolf.stackexchange.com/a/17414

I work in game dev in Unity and oh boy are they all backwards.

Some years ago they bought the best font rendering tool that a guy had written and incorporated it natively. Of course after that all work on it pretty much stopped and it killed the competitive font rendering market.

The other day I wanted to try and make an app that looks as if its using a native console font and I had to fiddle for 2+ hours to just get it to about 90% of the way there.

> So, full circle

In case anyone hasn't yet seen the 1968 full circle paper, "On the Design of Display Processors": http://cva.stanford.edu/classes/cs99s/papers/myer-sutherland...

Hardware in their case, but we also have software saṃsāra.

It is pretty clever for debug text if, for instance, textures aren't uploading properly. But uh... while it's cute that the OP compares sprite sheets to 16th century manual typesetting, the reality is that it took a printer's assistant an hour to layout a broadsheet of tiny metal slugs on a press, and it takes oh < 10ms to upload a spritesheet to a GPU, which is then infinitely configurable.

Not saying it's not a neat trick, it is.

> If anyone is interested in the a more common way that modern 3d rendering engines draw text, look up SDF text (and related techniques like MSDF etc.).

This is now at least a generation out of date. Pretty much everyone is now using approaches like https://sluglibrary.com, where one directly rasterises the font bezier curves in a shader.

I cooked up a (very basic) version of the concept a while back: https://www.shadertoy.com/view/sdXBDs

Going one step further still there's the option of evaluating font curves directly on the GPU, which can be high quality regardless of scale or perspective. That turns out to be very difficult to do efficiently but it can be done.

e.g. https://sluglibrary.com

Meshes and SDFs are much simpler on the GPU side but scaling them up too much can compromise accuracy, and scaling meshes down too much can introduce aliasing.

The answer I look for in "how does it perform?" is "VSCode stops eating hundreds to thousands of MB of my VRAM".

> You can find the "NES font" and other 8x8 pixel fonts around the web.

This is my favorite pixel font pack:

https://int10h.org/oldschool-pc-fonts/

Incoming trivia:

I finally found out recently that the "NES" font is from the 1976 arcade game Quiz Show. The font was used in other black-and-white Kee/Atari games. The font data is available in the quizshow MAME ROM set - split into nybbles for some reason.

This game was interesting - it stored question and answer data on a 8-track tape.

> understanding was that GPUs are especially efficient at rendering from textures, while being relatively slow at bit twiddling.

That understanding is very out of date. For GPU's made in the last 15 or so years a texture lookup is roughly 100 times as slow as a bitwise operation.

It depends on the application. It’s the easiest way especially if you might encounter right to left script, CJK or emoji. It is worthwhile to cache the textures, most text does not change every frame. It is good enough for us.

Generally you want to avoid wasting too much memory on a GPU, even today. That large text box texture also has to go over the PCI bus which can cause stalls depending on when its uploaded and if the GPU ends up having to evict resources. If you end up having a lot of independent texture text boxes being rendered by the comparatively slower CPU, that could add up quickly and cut into your budget.

Drawing using a glyph atlas is still a way better use of resources. Modern text rendering pipelines will also often use either SDF or encoded bezier curves to improve glyph legibility when scaling which is also a great way of saving more memory.

You can render the entire string before upload, but then you are essentially using a CPU render, which will be slower than having the GPU do the same thing.

FWIW, this method is also a texture despite being called “texture-less”; the texture is just stored in a different format and a different place. True textureless font rendering evaluates the vector curves on the fly.

It's huge. Passing data from CPU to GPU is most likely, 90% of time, the biggest bottleneck.

Drawing one quad to cover N characters and picking out a glyph in the shader is going to be faster than drawing individual quads for each character (for monospace fonts, anyway). But there are only so many characters you can fill the screen with, so it's probably not a huge difference in practice.

Regarding the upload part: at the end of the day, you have X bytes of glyphs and they need to get into GPU memory somehow. Whether you get them there as textures, as uniform data or as shader constants doesn't really matter performance-wise. If anything, doing it through shader constants as described in TFA is more expensive on the CPU side, since all those constant declarations need to be processed by the shader compiler.

What does matter on the GPU side is which memory hierarchy you hit when reading glyph data (texture fetches have a dedicated L1 cache on most GPUs, larger than the "normal" L1 cache I think) and what order the data is in (textures are usually stored in some version of Morton order to avoid cache misses when you're shading blocks of pixels). For a production atlas-based text renderer you probably want to use textures.

Edit: I misread the question; you were asking about drawing individual glyphs on the GPU vs. drawing an entire block of text on the CPU, right? This is a speed/space tradeoff, the answer is going to depend on how much memory you want to blow on text, whether your text changes, whether it needs to have per-character effects applied, and so on.

> Is it so much performance penalty to upload a small texture to GPU so you can't render the whole string to the texture in 2D and just display the texture onto two triangles?

It's not. This technique is more about getting text on the screen in the easiest way possible for debugging. You just add some data to your shader and poof, you get text.

The converse is, you write code to generate a font atlas (so more work), or go find and existing one and need to load it (so need to write loading code so more work). And/Or draw a full message into a texture (more work) and you'll need to cache that result until the message changes (more work)

On top of all of that, you need to manage resources and bind them into the system where as here no resources are needed.

but again, it's a technique for getting "debugging text" on the screen. It is not a solution for text in general.

Note that drawing text to textures is how most browsers and OSes work. They draw fonts into texture atlases dynamically (since a atlas for all of Unicode per font per size would take too much time and memory). They then use the texture atlas glyphs to make more textures of portions of the app's window. In the browser you can turn on show texture edges to see all textures. Rendering->Layer borders will outline each texture in cyan

No, they say they are not going to store a bitmap in a texture, which is not the same thing as embedding directly in the shader code.

You could compare that to storing some data in a separate file which needs to be read during runtime versus embedding the data directly in the source code.

On modern desktop GPUs, there’s nothing frame rate limiting in practice about the technique in the article. So much so, it probably doesn’t make sense to measure in FPS. I don’t know which native text rendering you’re thinking of, but some text rendering methods are very high quality and not super fast or optimized, and they might limit framerate if you did a full screen of text every frame. Usually in that case people will render to a texture so that it doesn’t have to be done every frame. There are also enough medium & high quality text rendering methods that are fast enough that you can do full screen text every frame without worrying about FPS at all, usually fast enough to draw text on top of the game’s 3d rendering that the text doesn’t even noticeably affect the game’s framerate.

IIRC every possible quadratic bezier curve (the kind used in truetype) can be rendered as one triangle and the equation in barycentric coordinates is identical for all possible curves, so you can just evaluate it in the shader with no extra vertex data.