2) Bear in mind that making the visuals match exactly merely allows the software renderer to be used, it doesn't allow indirect GLX (check your GLX server strings carefully).
LIBGL_ALWAYS_INDIRECT is quite a pain, (more so for XDMCP sessions). In my experience client-side rendering is what most people want if the display is remote. If the network load is too heavy for client-side the render load will very likely be too heavy for the software rasterizer. (And apps can use display lists to alleviate the network load.)
1) To further document "lots of people affected by this" (and I'm well aware I haven't gotten off my posterior to fix this either):
SuSE brought this up last year[1] and ended up shipping with this patch[2] (a band-aid):
- if (glx_direct) >driswDisplay = driswCreateDisp lay(dpy) ; >driswDisplay = driswCreateDisp lay(dpy) ;
- dpyPriv-
+// if (glx_direct)
+// dpyPriv-
[1] http://<email address hidden> /msg06684. html /bugzilla. novell. com/show_ bug.cgi? id=469280
[2] https:/
2) Bear in mind that making the visuals match exactly merely allows the software renderer to be used, it doesn't allow indirect GLX (check your GLX server strings carefully).
LIBGL_ALWAYS_ INDIRECT is quite a pain, (more so for XDMCP sessions). In my experience client-side rendering is what most people want if the display is remote. If the network load is too heavy for client-side the render load will very likely be too heavy for the software rasterizer. (And apps can use display lists to alleviate the network load.)