| |||||||||||||
St. Pierre: The Linux Graphics StackSt. Pierre: The Linux Graphics StackPosted Jun 25, 2012 18:18 UTC (Mon) by ebassi (subscriber, #54855)In reply to: St. Pierre: The Linux Graphics Stack by butlerm Parent article: St. Pierre: The Linux Graphics Stack
Presumably, GTK and Qt could be changed to rely on XRender and any other necessary extensions when they are available, instead of pre-compositing everything itself. this is what happens already. it turns out, though, that none (except older intel ones) of the modern GPUs are optimized for XRender's usage of trapezoids; as every GPU is, essentially, a programmable 3D pipeline, triangles are actually more suited for them. in point of fact, XRender is not at all a good drawing and compositing API. the proper drawing and compositing API is, actually, OpenGL. that is also why Cairo, which was born as the client-side XRender API, is now moving to GL internally, and its internals are in the process of being overhauled for that.
(Log in to post comments)
St. Pierre: The Linux Graphics Stack Posted Jun 26, 2012 17:09 UTC (Tue) by butlerm (subscriber, #13312) [Link]
>none of the modern GPUs are optimized for XRender's usage of trapezoids
Is it really a serious problem to convert trapezoids into a pair of triangles, or is the problem simply that trapezoid based rendering requires too many trapezoids period?
St. Pierre: The Linux Graphics Stack Posted Jun 26, 2012 21:56 UTC (Tue) by ebassi (subscriber, #54855) [Link]
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.
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.
St. Pierre: The Linux Graphics Stack Posted Jun 29, 2012 17:27 UTC (Fri) by daenzer (✭ supporter ✭, #7050) [Link]
The problem isn't trapezoids vs. triangles per se but that the XRender rasterization rules (and some other aspects of its semantics) don't match what GPUs can do natively (or ever could, even when XRender was invented). On modern GPUs, the XRender rasterization can be emulated in pixel shaders, but older GPUs require at least the rasterization to be done by the CPU.
|
|||||||||||||