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

https://cv.co.hu/csabi/drawing-text-performance-graphical-vs-console.html

by todsacerdoti • 9 months ago

10 18 9 months ago

cv.co.hu

time4tea• 9 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...

laserbeam• 9 months ago

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• 9 months ago

I agree.

evolighting• 9 months ago

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?

louisbourgault• 9 months ago

Thanks for that! I was finding it painful as well

unwind• 9 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• 9 months ago

It's specifically this:

  backdrop-filter: blur(6px);

aappleby2• 9 months ago

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.

dcrazy3• 9 months ago

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.

aappleby2• 9 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• 9 months ago

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_• 9 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.

afishhh2• 9 months ago

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.

dcrazy3• 9 months ago

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.

afishhh2• 9 months ago

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.

zokier• 9 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.

gschizas• 9 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.

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

Related Stories