On 11/26/14 8:52 PM, Nathan Kidd wrote: > A work-around for other proxies would be to make the faked function > query the asked-for connection first, and only supply fake information > if the extension is not found. All the 2D-Xserver GLX queries should be > checking if GLX is available anyway, and would not occur if the > extension isn't there. I think this change would push the "we need a > TLS flag" issue into, if not theoretical, at least unnecessary-for-now > territory.
OK, now you lost me. How would your patch prevent the issue from occurring in an X proxy like TurboVNC that lacks GLX? It's different with EoD, because your GLX implementation actually does something useful (implements client-side OpenGL rendering instead of server-side.) With the new (Xorg 7.7-based) TurboVNC implementation (the TurboVNC 2.0 evolving pre-release), it is technically feasible to add a GLX extension, but I still don't want to do it for the following reasons: -- TurboVNC has always been designed to work with VirtualGL, so philosophically, I don't admit that a software-only GLX extension is very useful. -- There is an easy workaround for the small percentage of users who might need to use TurboVNC with software OpenGL: http://www.turbovnc.org/Documentation/Mesa -- Implementing and maintaining a Mesa-based GLX extension is a pain. It's less painful for TigerVNC, because they can leverage the pre-compiled Mesa libraries and DRI modules from a specific operating system (but of course, that prevents the build from working on other operating systems.) One of the underlying principles of The VirtualGL Project has always been to avoid maintaining an OpenGL implementation. It is one of the few things that has kept me sane over the last 10 years. -- Not having a GLX extension serves as an important failsafe for VirtualGL. That way, if VGL fails, it's pretty obvious that it is failing, because OpenGL simply won't work. Otherwise, it can produce some hard-to-diagnose issues in which VGL appears to be working but things are just running really slowly. The problem is: performance issues are less likely to be reported as bugs, so this could cause some serious issues to remain unreported, whereas otherwise they would manifest as obvious bugs. ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk _______________________________________________ VirtualGL-Devel mailing list VirtualGL-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
