High performance graphics and text rendering on the GPU for... - Geller & Sermersheim - CppCon 2019

[@bernadettetreual]

The text rendering still looks quite sub-par. Spacing doesn't scale linearly. Also: "Currently only supports monospace, Western fonts" - unless this can be generalised to proper text rendering, it's just a toy.

[@younghsiang2509]

Correct...

[@jamesfaraday8545]

Correct, their typographic capabilities don't even meet minimum requirements of any application

[@bobweiram6321]

Agreed. As a cross-platform UI library, it falls on its face. It needlessly bypasses the far more comprehensive, native UI facilities usually provided by the target platform. As a GPU interface library, there are tons of competing engines with a higher-level of abstraction for domain specific purposes such as CAD, video production and gaming. Finally, looking at the code snippets, it doesn't appear to conform to modern C++'s language constructs. I do think, however, it might be a good base for developing custom graphics engines.

[@holz_name]

Good talk. Yes, please stop wasting my CPU time for rendering buttons and text. I think literally all GUI graphics libraries are using the CPU? Why...

[@JochemKuijpers]

Easier, better support and you need it as a fall back when there is no GPU anyway. GPU rendering is optional so more work to implement.

[@IllumTheMessage]

Excellent talk. Very helpful for the non-graphics guru developer.

[@ronensuperexplainer]

I'm a big fan of simple graphics

[@dipi71]

Something about the text rendering sounds fishy, and I think the downvotes reflect this. A fonts provides a glyph consisting of bezier/cubic spline outlines; convert those to polygons and render those. I don’t thing you'll lose any performance doing fonts the proper way.

[@xavierthomas1980]

Nah, Signed distance field is pretty much unrivaled for fonts. It has lower computing and memory need than what you suggest, but provide equivalent-ish quality.

[@beyondhelp]

Im actually curious about that. So lets say you have an engine clocking away at 90 fps, so to render the text you would convert the vectors and then present it, but then what happens when you render it to multiple surfaces, and then present that. Wouldn’t it be taxing to have to do many conversions every time you rendered to a surface?

[@victordrouinviallard1700]

For video games, Valve introduced a couple years ago this "Signed distance field" algorithm. This is indeed generated from a set of bezier splines but without having to compute every time. It's a very good algorithm.

[@Bestmann3n]

glyph rendering is a nasty rabbit hole of compromise and aesthetic trade-offs. that includes the polygonal approach. For starters you'll have to do anti-aliasing to avoid jagged edges. Moreover gpus generally "fill" in triangles 4x4 or more pixels at a time so having a bunch of small triangles actually wastes a lot of performance, this also means you'll have to re-triangulate depending on what size you are rendering(a single curvy glyph covering half the screen could easily use hundreds if not thousands of polygons, you don't want to use that same mesh for a size 8 character). The list of issues goes on. Search for "GPU-centered Font Rendering Directly from Glyph Outlines" if you want to see what kind of nastyness state of the art gpu font rendering involves. SDF fonts have their own issues(like corner artifacts, being slow to compute in real-time, and so on)

[@azarashikamen4098]

as far as i know, signed distance field technique is one of the most practical and well balanced solution... i know, there are some people trying to implement(and boast) "more advanced" things, but they are usually garbages.