Why don't GPUs have some hardware in them to make rendering text simpler? It seems like a pretty common function that every game has. Have you ever seen a game without any text in it?
Show HN: GPU text rendering with vector textures
61–70 of 91 posts
Re: Show HN: GPU text rendering with vector textures
#62Why don't GPUs have some hardware in them to make rendering text simpler? It seems like a pretty common function that every game has. Have you ever seen a game without any text in it?
Fixed-function hardware on GPUs is really on the way out.
Re: Show HN: GPU text rendering with vector textures
#63I really like this idea, but bezier curves are quite computationally difficult to use. There are many representations of these kind of continuous shapes which are much easier for this kind of processing.
For example I would try converting the bezier representation into an implicit HRBF representation (here is a good explaination in 3D http://rodolphe-vaillant.fr/?e=12). This representation should be much easier to process on the GPU - checking how much the point is inside/outside the glyph should only be one matrix multiplication which would make the computation in the actual shader really really fast.
Re: Show HN: GPU text rendering with vector textures
#64Earlier quoted context omitted.
The something you're missing is that we're used to see this done on the CPU, and it's not something CPUs are good at: Pages full of text rendered with scalable fonts involves either a huge number of bezier curves etc. or a huge number of small blits, though you can trade some of it off by spending huge amounts of memory pre-rendering and caching (but if you cache bitmaps at the character level, you will find it harde…
Sorry to sound like an old fart, but computers have been doing this for years, and no, caching rendered glyphs does not eat huge amounts of memory. e.g. RiscOS on ancient ARM processors, drawing sub-pixel anti-aliased text on a CPU that had no floating point. Even just 64kb of font cache to store the bitmaps could keep everything running blazingly fast. Of course, the font renderers have gotten smarter, and of course…
I have to quibble with blazing fast. What was the resolution on an A3000 or whatever. Pretty low. My recall was the anti-aliased text rendering was technically impressive, but practically less-so due to low-resolution. A SUN or Mac was quite a bit nicer. On the Archimedes rendering against a non-solid non-monochrome color was especially nasty.
In that case, caching very expensive rendering to improve performance makes complete sense. Nice Impression summary and screenshot here. http://www.iconbar.com/forums/viewthread.php?threadid=10197 Bear in mind running on a 4 MHz ARM3 I would think.
Now, with a sufficiently high-resolution display and a performant pixel shader, all the stupid caching and hinting logic can be thrown away, and effort can go instead into optimizing this technique, with no loss of generality, when rendering to arbitrary structures in the page.
Re: Show HN: GPU text rendering with vector textures
#65This 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.
I don't know why you are being downvoted, that is what is happening and I am not convinced that straight textures would be better. We already know that SDF textures are better than straight texture atlases anyway. The technique is obviously practical in some respect (since it renders a pdf faster than anything else I've seen) and the quality of the text is very sharp, even close up.
Super sharp lines when zoomed in may not seem like a big deal, but as you increase resolution you will reap the benefits since the same size text will be sharper.
Re: Show HN: GPU text rendering with vector textures
#66This 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 t…
> 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 think this is actually a harmful approach in most cases--all it does is reduce the number of vertices and slightly reduces overdraw in exchange for a lot more memory consumption and a lot more draw calls. Overdraw can be reduced in other ways, such as sorting front to back and taking advantage of early Z for opaque content. Web pages and PDFs are so totally not bound on either ROPs or VS, and are very sensitive to draw call count, that caching tiles to minimize overdraw is almost never worth it.
But this is somewhat off topic.
> 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.")
You definitely do. You're sacrificing a lot of performance for the rendering of each tile if you don't do that.
Re: Show HN: GPU text rendering with vector textures
#67Earlier quoted context omitted.
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.
I don't know why you are being downvoted, that is what is happening and I am not convinced that straight textures would be better. We already know that SDF textures are better than straight texture atlases anyway. The technique is obviously practical in some respect (since it renders a pdf faster than anything else I've seen) and the quality of the text is very sharp, even close up. Super sharp lines when zoomed in m…
> We already know that SDF textures are better than straight texture atlases anyway.
This is isn't true. SDF textures can be "better" for "some" applications (like games that want to display stencils mostly at arbitrary zoom levels without losing a lot of quality) but they're also visibly lower-quality compared to glyphs rendered by freetype at each one of these zoom levels.
So, for an application that simply displays lots of text while infrequently changing the glyph size, SDF textures are not a good solution.
Re: Show HN: GPU text rendering with vector textures
#68Earlier quoted context omitted.
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.
I don't know why you are being downvoted, that is what is happening and I am not convinced that straight textures would be better. We already know that SDF textures are better than straight texture atlases anyway. The technique is obviously practical in some respect (since it renders a pdf faster than anything else I've seen) and the quality of the text is very sharp, even close up. Super sharp lines when zoomed in m…
The FS is something like 200 lines (verified in the WebGL debugger). A blitting shader is about 5. If fragment shading load doesn't matter, then of course you don't need straight textures. But if you want to reduce the load on the GPU and do the efficient thing, without any quality loss, it's better to use atlases.
> We already know that SDF textures are better than straight texture atlases anyway.
Even that depends. SDFs are slow to construct and, because they have a special FS, you have to pay attention to the number of state changes. They do have the advantage (unlike this technique) of having a very simple FS--they can even be used in some fixed function hardware!--making it practical to rerasterize glyphs every frame.
> The technique is obviously practical in some respect (since it renders a pdf faster than anything else I've seen)
That says a lot about how existing PDF renderers are slow and nothing about what is the fastest thing to do on the GPU.
Re: Show HN: GPU text rendering with vector textures
#69I did a simpler, potentially faster approach that also does subpixel AA:
https://dl.dropboxusercontent.com/u/13285702/M3.png
https://dl.dropboxusercontent.com/u/13285702/M3-TTF8.png
https://dl.dropboxusercontent.com/u/13285702/morphic3-jenson...
https://dl.dropboxusercontent.com/u/13285702/Morphic3-TimesN...
http://www.jvuletich.org/Morphic3/Morphic3-201006.html
http://www.defensivepublications.org/publications/prefilteri...
Re: Show HN: GPU text rendering with vector textures
#70no 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.
Ridiculously high resolution displays are rapidly becoming the norm.