Live data from Hacker News

Show HN: GPU text rendering with vector textures

wdobbie.com

41–50 of 91 posts

Re: Show HN: GPU text rendering with vector textures

#41

This is really neat. Though in practice if you are using this kind of thing I'm pretty sure you will want to combine it with atlasing (i.e. construct an atlas of glyphs via render to texture). That's because it's a waste of time to rerasterize glyphs in the FS every frame (which appears to be 200+ lines) instead of caching the results and reducing the per-frame work to a 5-line FS that just blits. In most apps pans a…

Wait. I guess you did not read the article at all? It is all about atlasing. There are issues with atlas of glyphs; so rather than putting the whole glyphs in atlas, he slices the glyphs in a grid, the grid being defined by the intersection of the underlying Bezier curves. And then he puts the grid pieces in atlas.

> Wait. I guess you did not read the article at all? It is all about atlasing.

Yes, I understand the technique. Perhaps I should be more clear about my terminology. I'm using "atlas" in the narrow sense of "actual pieces of bitmap data stored in a texture". My point is that this technique should not be a substitute for atlasing in this sense, but could well be combined with it.

Re: Show HN: GPU text rendering with vector textures

#43
post #14
post #8

Earlier quoted context omitted.

Here's my experience on my local devices: * Quad i7 16 GBytes GTX 970 OSX FFox - perfectly smooth * iPhone 6s+ - very smooth * Nexus 6p - slightly jumpy / laggy but still impressive * Lumia 640 Windows Phone 10 - dFdx undeclared identifier (120,33) There may be issues with webgl on the MBP if it's using Intel graphics, but I'd be pretty disappointed to get worse performance than an iPhone ... For the curious, the Lum…

Yeah my rMBP uses an embedded Intel graphics card. The performance is horrible, ~2 fps, tried FF and Chrome.

Performance is pretty decent (around 48fps for a full page with lots of glyphs, 1080p) on my Intel HD 4400. This is on linux though. I hear the OS X intel drivers have some shader compiler pitfalls.

Re: Show HN: GPU text rendering with vector textures

#44

Great work! Is there any WebGL source available? The demo runs very poorly on my 15" MBP (late 2013, Intel Iris Pro). I'm not sure if it's just the sheer number of glyphs being rendered at once, or whether it's something specific that this GPU is having trouble with. Some related links for those interested in WebGL text rendering: 1 - https://github.com/Jam3/three-bmfont-text 2 - http://mattdesl.svbtle.com/material-d…

It's probably Apple's custom intel HD graphics driver. I'm getting 60fps on an intel HD Graphics 4400 on linux.

Re: Show HN: GPU text rendering with vector textures

#45
post #23

no subpixel rendering or hinting. Im confused - is there a problem with cpu rendered fonts that needs fixing? I didnt notice anything wrong last time I was reading schematics and datasheets on 4K monitor.

> Im confused - is there a problem with cpu rendered fonts that needs fixing?

Performance. Even if an inefficient painting algorithm manages to paint at 60 FPS (which is very much not the case in, for example, common Web apps), improving its performance can free up the CPU to do more things and can reduce power consumption.

Think about it. If your GPU is sitting there idle, why not use it and free up the CPU to do other things? Today, most apps that aren't games are woefully underutilizing the GPU. Programs ideally should be utilizing all the silicon in your device while working so the work can be done faster and the hardware can enter low-power mode quicker.

Re: Show HN: GPU text rendering with vector textures

#46
post #23

no subpixel rendering or hinting. Im confused - is there a problem with cpu rendered fonts that needs fixing? I didnt notice anything wrong last time I was reading schematics and datasheets on 4K monitor.

Don't know why you're getting downvoted. More performance is certainly always good, but without subpixel anti-aliasing the text will tend to look pretty crappy absent a ridiculously high resolution display.

Re: Show HN: GPU text rendering with vector textures

#47
post #23

no subpixel rendering or hinting. Im confused - is there a problem with cpu rendered fonts that needs fixing? I didnt notice anything wrong last time I was reading schematics and datasheets on 4K monitor.

The demo that zooms in and out of a PDF is much faster than it would be with CPU rendering. When you zoom in and out in an existing PDF viewer, it takes much longer than 1/60 sec to re-rasterize the page.

The CPU takes a long time to rasterize fonts. It only seems fast because the glyphs are cached. If you need text drawn in so many different sizes, like in that demo, the cache is not as effective.

Re: Show HN: GPU text rendering with vector textures

#48
post #2

Exactly what I needed, just as I was about to start screwing with distance fields or the like. THANK-YOU! Edit: I may have spoken slightly too soon, not since the technique isn't awesome, but because this isn't yet usable without an atlas generation tool that I don't know how to build. As far as performance goes, this is rendering a 124-page PDF (I know, just the glyphs...) utterly without lag using the GPU, on a 16…

I find it curious the number of people in this thread being amazed that high end i7 processors and graphics cards designed for gaming can passably render some text. Is there something I'm missing?

Re: Show HN: GPU text rendering with vector textures

#49
Nice work. The subdivision into cells and encoding into GPU textures is strongly reminiscent of the 2008 paper "Random-Access Rendering of General Vector Graphics" by Nehab and Hoppe [1].

Rotating the line samples is a rather interesting idea. Seems like that would converge to the equivalent of a convolution with a radial tent filter.

[1] http://w3.impa.br/~diego/publications/NehHop08.pdf

Re: Show HN: GPU text rendering with vector textures

#50

This is really neat. Though in practice if you are using this kind of thing I'm pretty sure you will want to combine it with atlasing (i.e. construct an atlas of glyphs via render to texture). That's because it's a waste of time to rerasterize glyphs in the FS every frame (which appears to be 200+ lines) instead of caching the results and reducing the per-frame work to a 5-line FS that just blits. In most apps pans a…

There's also the higher level—the thing web browser rendering engines do, where you generate a texture for each "tile" (single-layer viewport rectangle) of likely-to-be-static text, and carry those around until you have to zoom or the text changes.

I'm not sure if you need the medium-level (font atlasing) if you have both lower-level (bezier-curve atlasing), and higher-level (pre-composited "tiles.")

This is one of the reasons I really like WebGL, actually: for GUI elements, you can usually skip rendering them within the game altogether, instead using plain HTML+CSS controls positioned above the , where they'll be treated as separate "tiles" that aren't dirtied by whatever your game is doing. Imagine: relatively-static fully-RGBA-translucent stuff sitting on top of your animating viewport, composited into a final image each frame, "for free."

Post reply on HN