St. Pierre: The Linux Graphics Stack [LWN.net]

St. Pierre: The Linux Graphics Stack

Posted Jun 26, 2012 21:56 UTC (Tue) by ebassi (subscriber, #54855)
In reply to: St. Pierre: The Linux Graphics Stack by butlerm
Parent article: St. Pierre: The Linux Graphics Stack

the tessellation algorithm is completely different in case of triangles; trapezoids provide a different set of benefits and complexities (basing XRender on trapezoids was not done on a whim). and if you remove trapezoids tessellation then you basically chucked away the majority of XRender - so you might as well go with another API entirely.

plus, XRender has nothing to describe vertex shaders, or geometry shaders, and even the convolution filters are a poor version of the GL fragment shaders.

in practice, OpenGL provides a better API to talk to modern GPUs than XRender.

(Log in to post comments)

St. Pierre: The Linux Graphics Stack

Posted Jun 27, 2012 21:15 UTC (Wed) by butlerm (subscriber, #13312) [Link]

>OpenGL provides a better API to talk to modern GPUs than XRender

Using OpenGL to do 2D graphics strikes me as first class overkill. But if it is the only thing that a GPU can actually do well, then fine. I don't know why anyone at the application or toolkit levels would want to write OpenGL code to do 2D graphics rendering though, if there were any possible way they could avoid it.

The issue with remote access is worse - relying on a serialization of OpenGL on the wire to handle 2D over a low bandwidth channel would be insane, as in not fit for the purpose at all. As an actual wire protocol, XRender ought to be much better, simply because it is much simpler, much more stable, and much less likely to break.

However, if there is some sort of gratuitous impedance mismatch between XRender and the way GPUs like to see things, perhaps the designers of the next generation remote graphics rendering protocol could take that into account. I am curious what could be done in any case - it isn't at all obvious why using triangles instead of trapezoids for 2D graphics is going to make anything better. The source material is Bezier curves after all, not some sort of polygonal mesh.

St. Pierre: The Linux Graphics Stack

Posted Jun 29, 2012 12:33 UTC (Fri) by ebassi (subscriber, #54855) [Link]

Using OpenGL to do 2D graphics strikes me as first class overkill.

that's because you still assume that: a) there is such a thing as a separate 2D and 3D and b) that this fictitious separation applies to the hardware. both assumptions are entirely fallacious.

2D is just a special case of 3D; modern GPUs are just programmable 3D rendering pipelines, and OpenGL is just a vendor-neutral API to program them without using driver-specific API: it provides you with the API to compile and upload programs to the GPU, as well as uploading geometry and texture data to the GPU memory - that's it.

not only the separation of 2D and 3D does not exist anywhere near the software layer, it's also not in the hardware: there are no modern GPUs with separate 2D pipelines like they existed in the past - except some Intel stuff.

I don't know why anyone at the application or toolkit levels would want to write OpenGL code to do 2D graphics rendering though

I maintain a toolkit that uses OpenGL. Cairo has a GL rendering surface that allows you to use the device-independent API to draw high quality 2D content using GL. Qt does the same. ideally, you don't want app developers to fudge around with GL - it's an awful API, with lots design-by-committee-of-CAD-developers crap - unless you're a game developer. that's why people write toolkits on top of it, exactly like people wrote toolkits on top of Xlib.

this has happened on other platforms as well: CoreAnimation and CoreGraphics on MacOS and iOS are two APIs used to do 2D (and 2D-layers-in-3D-space) UIs based on OpenGL and OpenGLES; CoreAnimation is the base toolkit used to write the whole user interface on iOS. Windows has its own toolkit based on DirectX. Android moved from software rendering to hardware acceleration through GLES.

tl;dr: the world has changed in the past 10 years - both at a hardware and a software level. GPU manufacturers standardised on GL and DirectX as the API exposed to control their cards, and platform and UI design moved to those two as the preferred drawing API for implementing their user interfaces.