Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

cv.co.hu

Post reply on HN
Print view View original

21–30 of 42 posts

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

#22

Post by Snild »

cluckindan wrote: post #10

I wonder how the GPU version is implemented. One quad and one texture draw per glyph sounds very not scalable, but one quad per terminal, one texture atlas and one shader to draw glyphs from the atlas already sounds much better.

A terminal maximized on my screen says:

    ~$ echo $((2 * LINES * COLUMNS)) triangles
    34272 triangles
That's nothing for a modern GPU. For example, this benchmark[1] says to expect on the order of 10-800 million tri/s. At the low end of that, you'd have a frame time of 3.427ms -- 292 fps.

The original Playstation could do 180 000 textured polygons per second[2], so it could've managed ~5 fps. Of course, you wouldn't render that many chars at its available output resolutions anyway. :)

[1] https://github.com/ctsilva/triangle-rendering-benchmarks#:~:... [2] https://en.wikipedia.org/wiki/PlayStation_technical_specific...

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

#24

Post by Sharlin »

> So I tried something unconventional: draw each character once, cache it as a texture, and then just copy those textures around.

That’s more like the most conventional way to draw characters ever. Nobody goes around rendering filled Béziers any more than absolutely necessary. And conventionally conventionally, fonts were bitmaps in the first place!

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

#25

Post by taeric »

Sharlin wrote: post #24

> So I tried something unconventional: draw each character once, cache it as a texture, and then just copy those textures around. That’s more like the most conventional way to draw characters ever. Nobody goes around rendering filled Béziers any more than absolutely necessary. And conventionally conventionally, fonts were bitmaps in the first place!

Yeah, I confess I would have assumed that this was more common than otherwise.

Makes me curious how much of computing is losing perceived speed because we have moved to calculating everything on the fly? Easy example is website layout. Yes, some dynamic sites need to calculate a ton on the fly. Most sites, though, probably don't need to reflow everything nearly as often as they do. And fitting everything into the mechanism that is the document flow remains baffling to me.

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

#27

Post by jayd16 »

Snild wrote: post #22
cluckindan wrote: post #10

I wonder how the GPU version is implemented. One quad and one texture draw per glyph sounds very not scalable, but one quad per terminal, one texture atlas and one shader to draw glyphs from the atlas already sounds much better.

A terminal maximized on my screen says: ~$ echo $((2 * LINES * COLUMNS)) triangles 34272 triangles That's nothing for a modern GPU. For example, this benchmark[1] says to expect on the order of 10-800 million tri/s. At the low end of that, you'd have a frame time of 3.427ms -- 292 fps. The original Playstation could do 180 000 textured polygons per second[2], so it could've managed ~5 fps. Of course, you wouldn't ren…

But if they naively execute 15120 draw calls...

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

#28

Post by jiggawatts »

bardak wrote: post #21
9999_points wrote: post #3

This is "an entire doctoral research project in performant terminal emulation". https://github.com/microsoft/terminal/issues/10362#issuecomm...

I was wondering if Casey would end up a mention on this topic.

That really was just the most absurd argument for Microsoft developers to engage in. It felt like a parody of the "optimisation is unnecessary because us developers are such Prima Donnas and simply toooooo expensive to lower ourselves to such levels" attitude that some people have.

He used a cache. A simple hashtable. That's it. He got an absurd speedup of something like hundreds of times faster.

What are developers smoking these days that they can't even envision ever doing something like this without undertaking a research program?

To this day people will debate this, as if there's a valid debate to be had!

"No, no, no, it's premature to optimise software that is... being released to a billion users in production."

"Casey is adding unnecessary complexity that will be hard to maintain... by using a fraction of the code Microsoft did to solve the same problem."

"It must be full of errors... well... other than the superior Unicode compliance."

"It's so much longer to develop high-performance code... the evidence is that it took Casey two weekends to write a nearly complete terminal emulator!"

Etc...

Look where we are today. Microsoft still steadfastly refuses to even look at Casey's solution, let alone adopt it wholesale. Years later there are still blog articles being written about the performance issues of the Windows Terminal.

PS: Notepad and Calculator got the same "treatment" and now struggle to keep up with key presses.

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

#29

Post by mr_toad »

Sharlin wrote: post #24

> So I tried something unconventional: draw each character once, cache it as a texture, and then just copy those textures around. That’s more like the most conventional way to draw characters ever. Nobody goes around rendering filled Béziers any more than absolutely necessary. And conventionally conventionally, fonts were bitmaps in the first place!

> And conventionally conventionally, fonts were bitmaps in the first place!

Bitmaps in ROM on early machines.

https://en.wikipedia.org/wiki/Motorola_6845

Post reply on HN