Have you considered migrating to github from sourceforge, in light of their recent behavior? Sorry if this has already been addressed.
On Fri, Jun 12, 2015 at 8:19 AM, DRC <dcomman...@users.sourceforge.net> wrote: > http://sourceforge.net/projects/virtualgl/files/2.4.1/ > > Packaging changes: > These packages were built with libjpeg-turbo 1.4.1: > http://sourceforge.net/projects/libjpeg-turbo/files/1.4.1/ > This improves performance on 64-bit Mac clients, relative to VirtualGL 2.4. > > Significant changes since 2.4: > > [1] When an application doesn't explicitly specify its visual > requirements by calling glXChooseVisual()/glXChooseFBConfig(), the > default GLX framebuffer config that VirtualGL assigns to it now contains > a stencil buffer. This eliminates the need to specify > VGL_DEFAULTFBCONFIG=GLX_STENCIL_SIZE,8 with certain applications > (previously necessary when running Abaqus v6 and MAGMA5.) > > [2] VirtualGL will no longer advertise that it supports the > GLX_ARB_create_context and GLX_ARB_create_context_profile extensions > unless the underlying OpenGL library exports the > glXCreateContextAttribsARB() function. > > [3] Fixed "Invalid MIT-MAGIC-COOKIE-1" errors that would prevent > VirtualGL from working when vglconnect was used to connect to a > VirtualGL server from a client running Cygwin/X. > > [4] If a 3D application is rendering to the front buffer and one of the > end-of-frame trigger functions (glFlush()/glFinish()/glXWaitGL()) is > called, VirtualGL will no longer read back the framebuffer unless the > render mode is GL_RENDER. Reading back the front buffer when the render > mode is GL_SELECT or GL_FEEDBACK is not only unnecessary, but it was > known to cause a GLXBadContextState error with newer nVidia drivers > (340.xx and later) in certain cases. > > [5] Fixed a deadlock that occurred in the multi-threaded rendering test > of fakerut when it was run with the XCB interposer enabled. This was > due to VirtualGL attempting to handle XCB events when Xlib owned the > event queue. It is possible that this issue affected or would have > affected real-world applications as well. > > [6] Fixed an issue that caused certain 3D applications (observed with > CAESES/FFW, although others were possibly affected as well) to abort > with "ERROR: in TempContext-- Could not bind OpenGL context to window > (window may may have disappeared)". When the 3D application called > glXChooseVisual(), VirtualGL was choosing a corresponding FB config with > GLX_DRAWABLE_TYPE=GLX_PBUFFER_BIT (assuming that VGL_DRAWABLE=pbuffer, > which is the default.) This is incorrect, however, because regardless > of the value of VGL_DRAWABLE, VirtualGL still uses Pixmaps on the 3D X > server to represent GLX Pixmaps (necessary in order to make > GLX_EXT_texture_from_pixmap work properly.) Thus, VGL needs to choose > an FB config that supports both Pbuffers and Pixmaps. This was > generally only a problem with nVidia drivers, because they export > different FB configs for GLX_PBUFFER_BIT and > GLX_PBUFFER_BIT|GLX_PIXMAP_BIT. > > > ------------------------------------------------------------------------------ > _______________________________________________ > VirtualGL-Users mailing list > VirtualGL-Users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/virtualgl-users >
------------------------------------------------------------------------------
_______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
