Drawing Text Isn't Simple: Benchmarking Console Vs. Graphical Rendering

Posted3 months agoActive2 months ago

todsacerdoti

10 points

18 comments

cv.co.huTechstory

calmmixed

Debate

40/100

Text RenderingPerformance BenchmarkingConsole vs Graphical Rendering

Key topics

Text Rendering

Performance Benchmarking

Console vs Graphical Rendering

The article compares the performance of text rendering in console and graphical environments, sparking a discussion on the complexities and trade-offs involved in text rendering.

Snapshot generated from the HN discussion

Discussion Activity

Active discussion

First comment

Peak period

180-192h

Avg / period

Comment distribution18 data points

Loading chart...

Based on 18 loaded comments

Key moments

01Story posted
Oct 14, 2025 at 10:34 AM EDT
3 months ago
Step 01
02First comment
Oct 22, 2025 at 1:04 AM EDT
8d after posting
Step 02
03Peak activity
18 comments in 180-192h
Hottest window of the conversation
Step 03
04Latest activity
Oct 22, 2025 at 5:48 AM EDT
2 months ago
Step 04

Generating AI Summary...

Analyzing up to 500 comments to identify key contributors and discussion patterns

Discussion (18 comments)

Showing 18 comments

laserbeam

2 months ago

1 reply

You really do need units in your tables. It is not very obvious you are talking about FPS in them… or is it milliseconds or microseconds. The only place a unit of measurement is actually mentioned (FPS) is the window title of a screenshot.

rrgok

2 months ago

I agree.

evolighting

2 months ago

3 replies

This blog page feels laggy in Firefox, but it works fine in Chrome.

The floating menu with the frosted glass effect seems to be causing the problem, remove that div in F12, fix it. What’s the reason behind this?

unwind

2 months ago

Agree, it was kind of comical that a web page complaining about text rendering performance uses some kind of design that a) only has relevant content on ~half the screen and b) causes me to have to wait every time I move the scroll wheel. :|

fainpul

2 months ago

It's specifically this:

  backdrop-filter: blur(6px);

louisbourgault

2 months ago

Thanks for that! I was finding it painful as well

aappleby

2 months ago

2 replies

The "right way" to do this on the GPU if you're using a monospaced console font is to have a glyph atlas, a persistently mapped text buffer, a persistently mapped attribute buffer, and then draw a single triangle that covers the viewport and do absolutely everything else (text map lookup, attribute lookup, glyph atlas lookup, blending/compositing) in the pixel shader.

You should be able to hit 1000 fps with most modern GPUs, and the code is fairly simple after youve got the buffers and shaders set up.

dcrazy

2 months ago

1 reply

Fullscreen tri is not necessarily the way. If the GPU has significant penalties for rejecting fragments, or your text is sparse, you should probably use form-fitting quads or polys.

Also, monospace (and implicitly, Latin) is doing a huge amount of lifting in your comment.

aappleby

2 months ago

Of course, the example in the article is all monospaced console stuff. I've written a lot of text rendering over the years, everything from tiny bitmap for microcontrollers to analytically-antialiased true type based on code from some paper by Charles Loop years ago.

If GPU is cheap and CPU is expensive, draw one tri every frame and don't worry about the rest. If CPU is cheap and GPU is expensive, do a glyph per quad and some basic dirty rectangles if needed.

bschwindHN

2 months ago

1 reply

Essentially as it's described here, right?

https://www.youtube.com/watch?v=lStYLF6Us_Q&t=1472s

Casey refers to it as "backwards" rendering - starting from the pixel location and determining what should be drawn there, vs. "forward" rendering where you have things you want to draw, and you determine which pixels they will be drawn in.

Terr_

2 months ago

> Casey refers to it as "backwards" rendering

Sounds much like "backwards" raytracing in 3D, except with some special rules for an orthographic projection.

I know that "except with" makes it sound like a narrow refinement, but I suppose the history of computer display hardware likely has it the other way around.

afishhh

2 months ago

1 reply

> Drawing text isn't simple

I agree, but even this article seems to oversimplify.

> You can't really optimize texture copies much more.

Did the author try packing the textures in an atlas?

Texture atlases can improve performance significantly since then you can use instanced draw calls to draw a whole bunch of glyphs at once.

dcrazy

2 months ago

1 reply

FWIW you cannot have Unicode-correct rendering by caching at the codepoint (what many people would call “character”) level. You can cache bitmaps for the individual “glyphs”—that is, items in the font’s `glyf` table. But your shaping engine still needs to choose the correct “glyphs” to assemble into the extended grapheme clusters dictated by your Unicode-aware layout engine.

afishhh

2 months ago

1 reply

Exactly why I referred to drawing glyphs instead of characters :)

There's even more depth one can go into here: subpixel positioning. To correctly draw glyphs that may be on subpixel positions, you need to rasterize and cache glyphs separately for each subpixel position (with some limited amount of precision, to balance cache usefulness and accuracy).

However I have a feeling that describing an entire Unicode-aware text stack here may not be useful, especially if TFA seems to only care about simple-script monospace LTR.

dcrazy

2 months ago

Nowadays people expect their terminals to handle UTF-8, or at least the Latin-like subset of Unicode, without dealing with arcana such as codepages. For even the simplest fonts, rendering something like í likely requires drawing multiple glyphs: one for the dotless lowercase I stem, and one for the acute accent. It so happens that dotless lowercase I maps to a codepoint, but it is not generally true that a single extended grapheme cluster can be broken down into constituent codepoints. So even “simple” console output is nowadays complected by the details of Unicode-aware text rendering.

time4tea

2 months ago

Quite conventional - its how FreeType works.

Computing a bitmap for a glyph is expensive because of all the splines and whatnot.

https://freetype.org/freetype2/docs/tutorial/step1.html#sect...

gschizas

2 months ago

I feel that there might be a bigger difference by using Console Host vs Windows Terminal. Windows Terminal IIRC is GPU accelerated.

EDIT: The screenshot sure looks like Console Host.

zokier

2 months ago

There are like at least half dozen open source terminal emulators that have decent performance text rendering if you want to look into how it is really done. It is not simple, but at this point I feel it is a largely solved problem.

View full discussion on Hacker News

ID: 45580559Type: storyLast synced: 11/20/2025, 1:54:04 PM

Want the full context?

Jump to the original sources

Read the primary article or dive into the live Hacker News thread when you're ready.

Open link View on HN