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

Easy Scalable Text Rendering on the GPU

medium.com

Post reply on HN
Print view View original

21–30 of 42 posts

Re: Easy Scalable Text Rendering on the GPU

#21

Post by wtallis »

jacobolus wrote: post #20
wtallis wrote: post #8

Earlier quoted context omitted.

That essay is written from a particular perspective and pretends that it is the clearly right perspective. Whether it's valid to consider pixels to be little squares depends on whether we're talking about display pixels or image sensor pixels and whether we're trying to resample or interpolate photographic data or trying to create data (pixel art, fonts) for a specific display medium. Sometimes there simply isn't an…

Sensor pixels and display pixels also aren’t little squares, and treating them as such (whether for font rendering, photo capture, rendering line drawings, or any other purpose) is pretty much always worse than treating pixels as a discrete approximation of a continuous image. Unfortunately 2D approximation is inherently more complex than 1D approximation, so you inevitably get some artifacts even when you do fancy c…

> Sensor pixels and display pixels also aren’t little squares [...]

They're pretty damn close, modulo the Bayer pattern for most sensors and RGB stripe arrangement for most displays. Calling an LCD's subpixels rectangles is certainly an approximation that's valid on the scale of the distance from one pixel to the next.

> [...] and treating them as such (whether for font rendering, photo capture, rendering line drawings, or any other purpose) is pretty much always worse than treating pixels as a discrete approximation of a continuous image.

Whether treating those pixels as rectangles or points is worse depends as much on the software/analytic approach you're using as on the physical reality of their rectangular geometry.

> Unfortunately 2D approximation is inherently more complex than 1D approximation, so you inevitably get some artifacts even when you do fancy computationally expensive math, and the choice is about which type of artifacts to privilege.

True, if you're unjustifiably constraining yourself to treating computer graphics only with the methods of a generic signal processing problem. Bresenham's algorithm is radically simpler than anything involving Bessel functions and also happens to work very well in the real world both in terms of speed and visual quality. Adding antialiasing to it leaves you with something that's still extremely simple and is easy to explain in terms of pixels. An exhortation to never treat pixels as little squares is just plain wrong.

Re: Easy Scalable Text Rendering on the GPU

#23

Post by vvanders »

Negative1 wrote: post #12
pcwalton wrote: post #5

Earlier quoted context omitted.

Well, I'm a bit confused as to how this is fill-rate friendlier than something like [1]: if you are drawing and checking the winding rule via the stencil buffer or color buffer, then you're going to overdraw a lot. A technique like [1], on the other hand, only paints each pixel once. I would think that, compared to the LUT texture approach, this technique is lighter in FS load but more expensive in terms of fill rate…

Stencil check rejections based on overdraw don't hurt as much as you'd think. Liken it to a clip() (or discard), which is a single instruction. The GPU pipeline optimizes for this. The approach you linked too is very well thought out but each font still does pixel processing for a bezier curve, which is many orders more expensive than a clip(). Never mind the addition of a dependent read via the LUT and the tracing s…

A word of caution, not all pipelines are created equal(wrt to stencil/z-test/etc).

One other downside is this technique requires two drawcalls which can be pretty painful on some platforms.

Unless you really need large ranges of scale a glyph atlas based solution will probably be the fastest on a wide range of hardware.

Re: Easy Scalable Text Rendering on the GPU

#24

Post by jacobolus »

wtallis wrote: post #21
jacobolus wrote: post #20

Earlier quoted context omitted.

Sensor pixels and display pixels also aren’t little squares, and treating them as such (whether for font rendering, photo capture, rendering line drawings, or any other purpose) is pretty much always worse than treating pixels as a discrete approximation of a continuous image. Unfortunately 2D approximation is inherently more complex than 1D approximation, so you inevitably get some artifacts even when you do fancy c…

> Sensor pixels and display pixels also aren’t little squares [...] They're pretty damn close, modulo the Bayer pattern for most sensors and RGB stripe arrangement for most displays. Calling an LCD's subpixels rectangles is certainly an approximation that's valid on the scale of the distance from one pixel to the next. > [...] and treating them as such (whether for font rendering, photo capture, rendering line drawin…

Bresenham’s line algorithm works pretty well for how simple it is (especially assuming you are rendering on a CPU, circa 1970 – with GPUs available on every device it’s an anachronism which only persists through historical inertia), but rendering lines using supersampling on some not-so-rectangular grid and then using a high-quality antialiasing filter to integrate the samples looks strictly better every time, especially if you have a large number of thin lines. If you’re just rendering a couple simple shapes it probably doesn’t matter too much. If you’re trying to render a map or something then using better techniques makes a big difference.

[Unfortunately, even in the best case antialiased slightly diagonal straight lines look pretty shitty on a pixel display, regardless of what technique you use, up until you get to a pretty high resolution. Just an inherent issue with pixel grids.]

This paper is the overall most promising one I’ve seen in the field: http://w3.impa.br/~diego/projects/GanEtAl14/

Re: Easy Scalable Text Rendering on the GPU

#26

Post by jtxx000 »

jacobolus wrote: post #24
wtallis wrote: post #21

Earlier quoted context omitted.

> Sensor pixels and display pixels also aren’t little squares [...] They're pretty damn close, modulo the Bayer pattern for most sensors and RGB stripe arrangement for most displays. Calling an LCD's subpixels rectangles is certainly an approximation that's valid on the scale of the distance from one pixel to the next. > [...] and treating them as such (whether for font rendering, photo capture, rendering line drawin…

Bresenham’s line algorithm works pretty well for how simple it is (especially assuming you are rendering on a CPU, circa 1970 – with GPUs available on every device it’s an anachronism which only persists through historical inertia), but rendering lines using supersampling on some not-so-rectangular grid and then using a high-quality antialiasing filter to integrate the samples looks strictly better every time, especi…

Very cool paper.

Re: Easy Scalable Text Rendering on the GPU

#27

Post by jacobolus »

pcwalton wrote: post #2

Minus antialiasing, the stencil buffer version of this technique has been described in the Red Book for a long time: http://www.glprogramming.com/red/chapter14.html#name13

Also cf. the Loop/Blinn chapter in GPU Gems 3 http://http.developer.nvidia.com/GPUGems3/gpugems3_ch25.html

Re: Easy Scalable Text Rendering on the GPU

#28

Post by constexpr »

nice_byte wrote: post #22

Can anyone tell me how this compares to SDF in terms of both speed and quality?

This approach uses much less memory, gives a render that is exact instead of approximate (it doesn't suffer from corner clipping or grid resolution issues as you zoom in), and is quicker to do an initial render because there's no CPU-side preprocessing involved. I haven't profiled both techniques side-by-side though so I'm not sure which technique is ultimately faster.

Re: Easy Scalable Text Rendering on the GPU

#29

Post by a_e_k »

jtxx000 wrote: post #14
wtallis wrote: post #8

Earlier quoted context omitted.

That essay is written from a particular perspective and pretends that it is the clearly right perspective. Whether it's valid to consider pixels to be little squares depends on whether we're talking about display pixels or image sensor pixels and whether we're trying to resample or interpolate photographic data or trying to create data (pixel art, fonts) for a specific display medium. Sometimes there simply isn't an…

The paper is old, but it's actually a fairly trivial application of signal processing techniques that have been well-understood since the 40s. For sub-pixel anti-aliasing, the approach would be to 1. Construct the underlying continuous field. This is just a function f(x,y) that returns one if the point is within the text and 0 otherwise. 2. Convolve f with an anti-aliasing filter. The filter could be tall and skinny…

For what it's worth, you can find a nice detailed description of Microsoft's approach to sub-pixel anti-aliasing in "Optimal Filtering for Patterned Displays" [1]. There is also a follow-on, "Displaced Filtering for Patterned Displays" [2].

Interestingly, both papers feature an aliased zone plate. :-)

[1] http://research.microsoft.com/pubs/68972/optfilt.pdf

[2] http://research.microsoft.com/pubs/68631/sid2000.pdf

Re: Easy Scalable Text Rendering on the GPU

#30

Post by leni536 »

I don't get why zooming up the subpixel antialiased image and looking at the color fringes makes sense [1]. Why would you want to remove color fringes from here? That's not what you see, you see [2]. I don't see color fringes in [2].

[1] https://cdn-images-1.medium.com/max/1400/1*Uqt60m0luG2S8lm3h...

[2] https://cdn-images-1.medium.com/max/1400/1*VoJ6TfORiCHAHy3SN...

Post reply on HN