71–80 of 91 posts
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…
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…
It's very laggy and slow on a quad i7 16GB Macbook Pro. Presumably this is because of the retina display.
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 ot…
For games specifically I'd prefer more work done on CPU and free up the GPU, provided the communication overhead isn't too much and latency doesn't become a problem.
Low power is less of a problem than thermal limiting for compute intensive work. I see about 90% variation in test times on my laptop for unit tests, for example.
So overall I see more application for this in apps than games, and only then when the tradeoffs are right. It's not a simple call.
Earlier quoted context omitted.
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?
It's not so much they are amazed it capable of doing this. But more of a WOW this is fast compared to rendering theses slow PDF pages on the CPU. It's a bit like saying: wow this rocket propelled car is fast. Are we surprised it is faster ? No. Are we like: "wow we could go faster !"? Yes To be fair, I don't understand why we don't have a lib, or even this stuff build into OpenGL/Direct3D. We are doing raster work CP…
Nvidia has it's nvPathRendering extension to OpenGL https://developer.nvidia.com/nv-path-rendering
I'm not aware of a fully portable equivalent to either of these two libs.
Earlier quoted context omitted.
> 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 ot…
On a modern PC games use a small fraction of the CPU and the GPU is the bottleneck. The only applications that really strain the CPU (i.e. all cores) are trivially parallelizable ones like transcoding, compilation, test suites, etc. For games specifically I'd prefer more work done on CPU and free up the GPU, provided the communication overhead isn't too much and latency doesn't become a problem. Low power is less of…
Also, I care quite a bit about power draw because my customers on laptops and mobile are very sensitive to it. If my game is a battery hog, it doesn't get played as long or as often.
Earlier quoted context omitted.
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.
I can see questioning the utility for current 2d applications but this is really critical speed when the large amount of translation and scaling of many pages in a 3d environment is the expectation.
The css3d "portal" solution for webgl doesn't seem like it can get us very far at all...
I'd use this today in my webvr/gl project if it was source complete.
Earlier quoted context omitted.
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 make…
Just about everything in computing is a form of caching. It's rarely stupid, so throwing it out is short-sighted.
Earlier quoted context omitted.
> 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 ot…
On a modern PC games use a small fraction of the CPU and the GPU is the bottleneck. The only applications that really strain the CPU (i.e. all cores) are trivially parallelizable ones like transcoding, compilation, test suites, etc. For games specifically I'd prefer more work done on CPU and free up the GPU, provided the communication overhead isn't too much and latency doesn't become a problem. Low power is less of…
Earlier quoted context omitted.
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…
The font atlas is definitely still worth it. For example: your comment, which fits in a single browser tile, is made up of 735 drawn glyphs. There are 50 distinct glyphs used (not counting italics because I'm lazy). Assuming it takes twice as long to draw a glyph into an atlas but half as long to draw it once it's in the atlas, an atlas that starts completely empty will speed up text drawing for your comment by 66% (…
• Most frames won't involve zooming or text-change—and therefore will be handled at "zero" time-cost by re-using the pre-composited tile.
• The frames that do involve text-change (but not zoom) can benefit from font-atlasing.
• The frames that involve discrete zoom, where text goes from one integral font size (represented in the atlas) to another integral font size (also in the atlas) can also benefit from font-atlasing.
• The frames that involve continuous zoom—such as in this demo—can't benefit from font-atlasing, because the frames where the font is e.g. 7.037773pt large can't be served from the atlas.
Keep in mind that the only reason we do discrete zoom-levels in PDF readers, text editors, etc. is that font-atlasing is "the optimization we have", and it calls for discrete zoom levels. When the UX affordance is for continuous zoom—think about pinch-to-zoom in Mobile Safari, or about zooming into Google Earth—font-atlasing doesn't and can't work. But this technique can.
Now, in games in particular, "continuous zoom" is a pretty rare edge-case. GUI elements don't tend to get zoomed into[1].
And "in-VR" elements, like street signs in an FPS, aren't usually designed as a bunch of geometry[2], but rather as a very high-detail flat texture that maybe gets mipmapped from far away. "Zooming" by approaching a street sign doesn't make the fonts on it re-render themselves; there are no fonts on it, they're just baked into an image.
---
[1] Well, maybe; I could see a case for continuous zoom of the fonts—and other GUI geometry—plastered over units in RTS games. "Pan up" with units selected, they stay selected but their unit names+stats get smaller and smaller and eventually get obscured by draw-distance and atmosphere effects, just as if they were actually "there" in the scene instead of part of the GUI. (Makes me think of the windows in the TV show ReBoot.)
[2] This does make me imagine a Blade Runner-esque game full of holographic signs, though. Those could definitely benefit from this approach.)