Except OpenGL, I never used those libraries, but I'm going to try to guess, by reading wikipedia pages, like you did.
You seem right about Mesa. Here is the additional info we have :
"The X window system is a computer software system and network protocol that provides a basis GUIs for networked computers. It creates a hardware abstraction layer."
"GLX enables programs wishing to use OpenGL to do so within a window provided by the X Window System.
GLX consists of three parts:
- An API that provides OpenGL functions.
- An extension of the X protocol, which allows the client to send 3D rendering commands
- An extension of the X server that receives the rendering commands from the client and passes them on to the installed OpenGL library
If client and server are running on the same computer and an accelerated 3D graphics card is available, the former two components can be bypassed by DRI. The client program is then allowed to directly access the graphics hardware."
"Direct Rendering Infrastructure (DRI) is an interface used in the X Window System to allow user applications to access the video hardware without requiring data to be passed through the X server."
"Open Inventor is a C++ 3D graphics API designed to provide a higher layer of programming for OpenGL"
To make things simpler, let's imagine a simplified flow of data (and commands) that happens at the entries and exits of each of those APIs. At the very beginning we have your application program (compiled code), that you run from your computer. At the end we have images that are displayed on your screen.
There are several cases which I will restrain to the answers to these questions:
-does your computer have a graphic card (GPU), or only a CPU, to process graphic functions ?
-is your application embedded in a window of the x-window system ?
-if you use the x window system, is the "x server" running on your computer or on an other computer on the network ?
I'll assume you have the drivers for your GPU if you have one, and that you have Mesa for the software rendering).
First scenario : you run a graphic application written with OpenInventor, without using to the X Window System, and you don't have a graphic card. The program flow would be quite similar to :
Your application
↓ (uses functions of)
OpenInventor
↓ (calls functions declared by)
OpenGL
↓ (redirects function calls to implementation defined by)
Mesa
↓ (implemented OpenGL functions to be run on the CPU)
[Probably] Operating System rendering API
↓
3D Images on your screen
What happens here is called "software rendering" : the graphics command are not handled by any graphic hardware, but instead by your usual CPU, the processor that generally runs software.
Second scenario : now imagine that with the same conditions as above, you have a graphic card. The flow would look more like this :
Your application
↓ (uses functions of)
OpenInventor
↓ (calls functions declared by)
OpenGL
↓ (redirects function calls to implementation defined by)
Proprietary Drivers
↓ (converts OpenGL commands to GPU commands)
Graphic Card
↓
3D Images on your screen
What happens now is called "hardware acceleration", usually faster than the first scenario.
Third scenario : now let's introduce the X Window System flow, or at least how I think it is, based on the few Wikipedia lines I read.
Let's forget about the graphic hardware and API for a while. The flow should look like :
Your application (X Window System sees it as an "X Client")
↓ (sends requests defined by the X Window System Core Protocol)
X Server
↓ (convert your request to graphic commands)
[Probably] Operating System rendering API
↓
Windows or 2D images on your screen
Note that when using the X Window System, your screen and the computer from which you run your application may not be "directly" connected, but could be connected through a network.
Fourth scenario : suppose you want to add fancy 3D graphic renderings to your X Client application from the previous example. It seems to me that the X Window System is not originally able to do this, or at least it would necessitate much convoluted code to perform the equivalent of an OpenGL API function.
Luckily you can use GLX to add support for OpenGL commands to the system. You now have :
Your application
↓ (sends graphic requests defined by the "GLX extension to the X Protocol")
X Server with the GLX extension
↓ (convert your request to OpenGL commands)
OpenGL
↓ (redirects function calls to implementation defined by)
...
Now you can reconnect that last arrow to the one after "OpenGL" in the first scenario : you can get 3D images on your screen !
Finally about what I think understand of the DRI :
It seems to allow Mesa to have access to the GPU, so that would modify the flow of our first scenario into :
...
↓
Mesa
↓ (forwards OpenGL commands)
DRI
↓ (converts OpenGL commands to GPU commands)
Graphic Card
↓
3D Images on your screen
And it also seems to short-circuit the flow when using GLX, given the condition that its server and client are on the same computer, and that you have a GPU. In that case the graph of our fourth scenario would simply become :
Your application
↓ (sends graphic requests defined by the "GLX extension to the X Protocol")
DRI
↓ ("catches" OpenGL commands and converts them to GPU commands)
Graphic Card
↓
3D Images on your screen
That's it !
Now keep in mind that I'm not an expert in Unix environments, so my best advice is to study the documentation of each of those APIs to know precisely what they can do.
Combining the previous chart into a single one might make things easier to understand. I let this as an exercice to you!
Best Answer
update: See bottom of reply
This answer comes a bit too late, but I hope to shine light to others (particularly now that C++ standard committee wants to incorporate Cairo into std):
The reason nobody really cares about "accelerated vector graphics" is because of how GPUs work. GPUs work using massive parallelization and SIMD capabilities to colour each pixel. AMD typically works in blocks of
64x648x8 pixels while NVIDIA cards typically work in32x324x4 pixels [See update at the bottom]Even if they're rendering a 3D triangle, the GPU works on whole quads that this triangle covers. So if a triangle doesn't cover all 8x8 pixels in the block (or 4x4 in the case of nvidia) the GPU will compute the colour of uncovered pixels and then discard the result. In other words, the processing power for uncovered pixels is wasted. While this seems wasteful, it works incredibly good for rendering large 3D triangles when paired with a massive number of GPU cores (more detailed info here: Optimizing the basic rasterizer).
So, when we look back at vector based rasterization, you'll notice that when drawing lines, even if they're thick, there is a massive blank space. A lot of processing power wasted, and more importantly bandwidth (which is the major cause of power consumption, and often a bottleneck) So, unless you're drawing an horizontal or vertical line with a thickness multiple of 8, and it perfectly aligns to 8 pixel boundaries, a lot of processing power and bandwidth will be wasted.
The amount of "waste" can be reduced by calculating the hull to render (like NV_path_rendering does), but the GPU is still constrained to 8x8/4x4 blocks (also probably the NVIDIA's GPU benchmarks scale better with higher resolutions, the pixels_covered / pixels_wasted ratio is much lower).
This is why many people don't even care about "vector hw acceleration". GPUs simply aren't well suited for the task.
NV_path_rendering is more the exception than the norm, and they've introduced the novel trick of using the stencil buffer; which supports compression and can significantly reduce bandwidth usage.
Nonetheless, I remain skeptic of NV_path_rendering, and with a bit of googling shows that Qt when using OpenGL (aka the recomended way) is significantly faster than NVIDIA's NV_path_rendering: NV Path rendering In other words, NVIDIA's slides were "accidentally" comparing XRender's version of Qt. Ooops.
Instead of arguing that "everything vector drawing with hw acceleration is faster", Qt developers are more honest admitting HW accelerated vector drawing is not always better (see how their rendering works explained: Qt Graphics and Performance – OpenGL)
And we've not touched the part of "live editing" vector graphics, which requires triangle strip generation on the fly. When editing complex svgs, this could actually add serious overhead.
Whether it is better or not, it highly depends on the applications; as to your original question "why it hasn't taken off", I hope it is now answered: there are many disadvantages and constraints to take into account, often making a lot of people skeptical and may be even biasing them into not implementing one.
update: I've been pointed out the numbers are completely off base, as the mentioned GPUs don't rasterize in 64x64 & 32x32 blocks but rather 8x8 = 64 and 4x4 = 16. This pretty much nullifies the conclusions of the post. I will soon update this post later with more up to date information.