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

31–40 of 42 posts

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

#31

Post by xeonmc »

jiggawatts wrote: post #28
bardak wrote: post #21

Earlier quoted context omitted.

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…

On the other hand you have the new Microsoft Edit which is some guy’s weekend TUI project that got canonized by MS.

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

#32

Post by estimator7292 »

mr_toad wrote: post #29
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

Bitmaps in diode arrays on even earlier machines

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

#33

Post by samdoesnothing »

jayd16 wrote: post #27
Snild wrote: post #22

Earlier quoted context omitted.

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...

Same texture so a single draw call probably?

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

#34

Post by 6510 »

9999_points wrote: post #3

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

> What this code needs to do is extremely simple and it seems like it has been massively overcomplicated.

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

#35

Post by 6510 »

jiggawatts wrote: post #28
bardak wrote: post #21

Earlier quoted context omitted.

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…

In time we will be using hp printers for fast reliable text output.

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

#36

Post by kaelwd »

9999_points wrote: post #3

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

The author of that issue has a whole video series about it: https://www.youtube.com/watch?v=hxM8QmyZXtg

A way faster terminal emulator demo: https://github.com/cmuratori/refterm

And a terminal rendering benchmark tool: https://github.com/cmuratori/termbench

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

#37

Post by mfabbri77 »

jayd16 wrote: post #7
bob1029 wrote: post #6

SDF seems to be one of the better solutions for text rendering. Valve had this problem solved since 2007. I'd argue this technique is a big part of what gave TF2 its impressive visual style. That game ran at 100+ fps on hardware like the 8800GT at the time. https://www.redblobgames.com/x/2403-distance-field-fonts/

SDF is awesome but even then it's not a silver bullet. It's a raster technique and some people want vector fonts or subpixel rendering.

I don't know how common it is in fonts, but for generic 2D vector graphics, problems arise from the management of self-intersections, i.e., the pixels where they fall. With an SDF rasterizer, how do you handle the pixel where two Bezier curves intersect in a fish-shaped path? For this reason, more conventional rasterizers with multisampling are often used, or rasterizers that calculate pixel coverage analytically, also finding intersections (sweepline, Bentley-Ottmann).

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

#38

Post by wmanley »

wmanley wrote: post #15
krstffr wrote: post #2

This website almost crashed my m1 macbook pro (renders at 1 fps or something), so I guess point taken: rendering text is not simple!

Looks like it's caused by `backdrop-filter: blur(6px);` on `.menu-content`. After disabling that it's slow, but not that slow. Edit: This is with Firefox 144 on Ubuntu 22.04

It's also perfectly responsive if you disable JavaScript. Maybe something related to the --positionX and --positionY CSS variables that are updated on every mouse move?

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

#39

Post by wmanley »

wmanley wrote: post #15
krstffr wrote: post #2

This website almost crashed my m1 macbook pro (renders at 1 fps or something), so I guess point taken: rendering text is not simple!

Looks like it's caused by `backdrop-filter: blur(6px);` on `.menu-content`. After disabling that it's slow, but not that slow. Edit: This is with Firefox 144 on Ubuntu 22.04

No, actually the biggest difference is removing the `filter` property from the `.wave2` class which is used for rendering the background. With that removed the page is responsive even with the backdrop-filter - and it makes no visual difference AFAICS.
Post reply on HN