DRI For 2D Graphics?
Dan Farrell asks: "I know that we have DRI working good for 3D direct rendering. But DRI is quite a good infrastructure, why aren't we using it for 2D graphics as well? It seems to me that all of the complaints about X would disapprear if we got the Render extention finished, and used DRI to directly render everything(and maybe made X multithreaded and had it automatically re-nice itself... but that is me being greedy). I guess what I want to know is why we aren't using DRI for 2D graphics and video?"
Not necessarily. X is smart enough to know what tricks to enable when the display is on the local machine. For example, for a local display, all the X protocol traffic is being done via shared memory instead of the TCP/IP protocol stack. Several years ago this wasn't the case and one had to explicitly set the $DISPLAY variable to enable it.
I don't know much about the specifics of DRI, but if it's like what SGI did w/ GLX, they you should still be able to export the display to another machine and get some hardware assisted rendering. IIRC, the GLX extension would send the 3D information over the network to an X server capable of handling it. The server would pass it off the the gl layer that SGI built whether it was totally in software for the lowend machines or one of their massive multicard 3D units (or at least that how I remember it from the gl class I took at SGI several years ago). Yet another X extension that the server has to advertise. If an application needs this capability, it will have to query the server when it starts up and fall back to another rendering method or just complain to the user and exit. Sure it's not going to be as fast since it has to go over the network, but it is better than trying to do 3D w/ the plain X protocol.
the good ground has been paved over by suicidal maniacs