Slashdot Mirror
Glyphy: High Quality Glyph Rendering Using OpenGL ES2 Shaders
Recently presented at Linuxconf.au was Glyphy, a text renderer implemented using OpenGL ES2 shaders. Current OpenGL applications rasterize text on the CPU using Freetype or a similar library, uploading glyphs to the GPU as textures. This inherently limits quality and flexibility (e.g. rotation, perspective transforms, etc. cause the font hinting to become incorrect and you cannot perform subpixel antialiasing). Glyphy, on the other hand, uploads typeface vectors to the GPU and renders text in real time, performing perspective correct antialiasing. The presentation can be watched or downloaded on Vimeo. The slide sources are in Python, and I generated a PDF of the slides (warning: 15M due to embedded images). Source code is at Google Code (including a demo application), under the Apache License.
Now that is something I would like to have. And probably moving to this rendering described here removes that option.
is the weirdest presentation that I ever saw on slashdot.
#
#\ @ ? Colonize Mars
#
I would love to know if this can be made to work with WebGL. There are so many possibilities in web applications for really nice font management.
I've often thought the great potential of Microsoft's DirectWrite was wasted on Direct3D. Having an Open replacement provides so many more opportunities.
Whoever came up with blurry-color subpixel font rendering should be shot. I understand the theory, but it's an optical illusion that is incompatible with my eyeballs. Worse, subpixel rendering is the default in all kinds of places. My eyes hurt just thinking about it. Please oh please do not let this (otherwise very cool idea) make the problem even worse.
Current OpenGL applications rasterize text on the CPU using Freetype or a similar library, uploading glyphs to the GPU as textures. This inherently limits quality and flexibility (e.g. rotation, perspective transforms, etc. cause the font hinting to become incorrect and you cannot perform subpixel antialiasing).
Wow, I never realized rendering text was such a royal pain in the ass.
An enigma, wrapped in a riddle, shrouded in bacon and cheese
downloading that sucker could have taken down the entire Internet. ;) :D
Is a goal of vector rendering, beyond gaming, eventually have the UI completely vector based? Be it desktop, or mobile device?
I just know with systems in the past, for curiousity purposes, dragging a windowed program around, text based or other, would cause a cpu spike and plateau till I stopped. This was on both windows and linux. I'm just wondering if this, glyphy, presumably alleviates a possible roadblack to a completely vector based UI, away from the CPU. It's pretty clear in the presentation that cpu crunching is ignored with the text manipulation he does. It always amazed me of how much graphical elements would seem to spike a cpu, on any OS. It would seem unintuitive to think the gpu was the problem in those cases, but you might be hard pressed with todays hardware offering to see those particular problems persist.
Subpixel text rendering is just antialiasing with the red channel offset by a third of a pixel in one direction and the blue channel by a third of a pixel in the other direction. I'd compare it to anaglyph rendering, which offsets the camera position in the red channel by one intrapupil distance from the green and blue channels so that 3D glasses can reconstruct it. If the rest of your system performs correct antialiasing of edges (FSAA, MSAA, etc.), the video card will do the subpixel AA for you.
The PDF mentions another technique I've read about in Team Fortress 2, called "SDF" or "signed distance field" fonts. This makes a slight change to the rasterization and blitting steps to store more edge information in each texel. First the alpha channel is blurred along the edges of glyphs so that becomes a ramp instead of a sharp transition, and the glyphs are uploaded as a texture. The alpha forms a height map where 128 is the center, less than 128 is outside the glyph by that distance, and more than 128 is inside the glyph by that distance. This makes alpha into a plane at any point on the contour. The video card's linear interpolation unit interpolates along the blurred alpha, which is ideal because interpolation of a plane is exact. Finally, a pixel shader uses the smooth-step function to saturate the alpha such that the transition becomes one pixel wide. This allows high-quality scaling of bitmap fonts even with textures stored at 32px or smaller. It also allows programmatically making bold or light faces by setting the transition band closer to 96 or 160 or whatever. But it comes at the expense of slightly distorting the corners of stems, so it's probably best for sans-serif fonts.
The PDF also mentions approximating the outline as piecewise arcs of a circle, parabola, etc. and drawing each arc with an arc texture. This would be especially handy for TrueType glyph outlines, which are made of "quadratic Bezier splines", a fancy term for parabolic arcs.
One of the techniques described in the video is signed distance field (SDF) rendering, where the alpha channel is blurred to indicate distance from the ideal contour. Here's a video of it in action. It won't help if you're on dial-up or EDGE, but you should be able to get the idea if you're on any sort of broadband.
There is NOTHING that the GPU can do that software rendering on the CPU cannot do. There MAY be a speed penalty, of course (and were you using the CPU to render a 3D game, rather than your GPU, the speed penalty would in in the order of thousands to tens of thousands of times slower).
The reverse is NOT true. There are rendering methods available on the CPU that the GPU cannot implement, because of hardware limitations. Take COVERAGE-BASED anti-aliasing, for instance.
On the CPU, it is trivial to write a triangle-fill algorithm that PERFECTLY anti-aliases the edges by calculating the exact percentage of a pixel the triangle edges cover. Amazingly, this option is NOT implemented in GPU hardware. GPU hardware uses the crude approach of pixel super-sampling- which can be thought of as an increase in the resolution of edge pixels. So, for instance, all 4x GPU anti-aliasing methods effectively increase the resolution of edge pixels by 2 (so a pixel becomes in some sense 2x2 pixels).
Edge coverage calculations, while trivial to implement in hardware, were never considered 'useful' in common GPU solutions.
A 'GLYPH' tends to have a highly curved contour, which sub-divides into a nasty mess of GPU unfriendly irregular tiny triangles. GPUs are most efficient when they render a stream of similar triangles of at least 16 visible screen pixels. Glyphs can be nasty, highly 'concave' entities with MANY failure conditions for fill algorithms. They are exactly the kind of geometric entities modern GPU hardware hates the most.
It gets WORSE, much much worse. Modern GPU hardware drivers from AMD and Nvidia purposely cripple common 2D acceleration functions in DirectX and OpenGL, so they can sell so-called 'professional' hardware (with the exact same chips) to CAD users and the like. The situation got so bad with AMD solutions, that tech sites could not believe how slowly modern AMD GPU cards rendered the new accelerated Windows 2D interface- forcing AMD to release new drivers that backed off on the chocking just a little.
Admittedly, so long as accelerated glyph rendering using the 3D pipeline, and ordinary shader solutions, the crippling will not happen- but the crippling WILL be back if non-gaming forms of anti-aliasing are activated in hardware on Nvidia or AMD cards. Nvidia, for instance, boasts that drawing anti-aliased lines with its 2000dollar plus professional card is hundreds of times faster than doing the same with the gaming version of the card that uses the EXACT same hardware, and actually has faster memory and GPU clocks.
It gets WORSE. Rendering text on a modern CPU, and displaying the text using the 2D pipeline of a modern GPU is very power efficient. However, activate the 3D gaming mode of your GPU, by accelerating glyphs through the 3D pipeline, and power usage goes through the roof.
I ran into font edges with fringes and halos 2 years back when trying to render an 8-bit luminance font with an arbitrary user specified color. (Blue was the worst offender for fringes.)
I wasn't aware of the Valve's clever SDF solution at the time so I used a different 3-fold solution:
* Generate the texture font atlas offline using custom code + FreeType2
Each font is "natively" exported at various sizes from 8 px up to 72 px.
* Use pre-multiplied alpha blending for rendering instead of the standard alpha blending
gl.enable( gl.BLEND );
gl.blendFunc( gl.ONE, gl.ONE_MINUS_SRC_ALPHA );
* Fix the fragment shader to use pre-multiplied alpha:
We also pass in vertex alpha to allow each rendered font to "fade out to nothing" hence the non obvious "fade = vvTexCoord.z".
Since the designers aren't doing arbitrary rotations nor scaling our solution looks great.
My boss sent me a link to this article just after I saw it so looks like I'm off to research how easy / hard using SDF is into our WebGL font rendering system. :-)
There are so many possibilities in web applications for really nice font management.
Which are all wasted if the end user's browser lacks WebGL support entirely, as is the case with all web browsers for iPhone or iPad, or if the end user's browser detects insufficiency in the underlying OpenGL implementation, as my browser does (Firefox 26.0 on Xubuntu 12.04 LTS on Atom N450). All I get is "Hmm. While your browser seems to support WebGL, it is disabled or unavailable. If possible, please ensure that you are running the latest drivers for your video card", even after doing sudo sh -c "apt-get update; apt-get upgrade" this morning. In about:support I get "Driver Version: 1.4 Mesa 8.0.4" and "WebGL Renderer: Blocked for your graphics card because of unresolved driver issues."
So what fallback would you choose to use when WebGL is unavailable?
Why would you ever need to overscan HDMI?
Because television video is authored with early-adopter CRT HDTVs (and thus with overscan) in mind.
The guy in the video needs a lot of it before he gives a public speech again.
If you're on a monitor then it should not be messing with the signal at all.
If you're on a TV, then it's expecting consumer-grade TV signals and will futz with it. On some better TVs there is a way to tell it that it's a computer signal and then it will skip the mangling and just show it as-is.