Menu
▾
▴
virtualgl-users
|
From: Dr. R. G. <gro...@mh...> - 2015-03-17 14:43:31
Attachments:
ss_GWS_01.png
ss_GWS_02.png
|
Dear mailing list members, Are there any known problems of VirtualGL with Qt5? I'm working on a project (extensions to ITKSnap: https://github.com/pyushkevich/itksnap/pull/1) which has just recently moved to Qt5 and since then it seems that windows resizes do not work properly any more (new regions in the program stay black or contain artefacts, see *01.png) if the program is run with vglrun. Neither resizing the main window with the mouse, nor maximize, nor programmatical resizing works, this being the biggest problem, because the program does so for specific modes, one of these is the extension I work on. If I compile and run the application on my desktop PC everything works as expected (see *02.png). However, if run from a server with otherwise functioning VirtualGL it does not work, nor if recompiled on the server. It does work on the server for older versions of ITKSnap that build with Qt4. All together it gives me the impression the problem comes from the combination of VirtualGL with Qt5. Many thanks for any help or hints how to solve this. Roman -- Dr. Roman Grothausmann Tomographie und Digitale Bildverarbeitung Tomography and Digital Image Analysis Institut für Funktionelle und Angewandte Anatomie, OE 4120 Medizinische Hochschule Hannover Carl-Neuberg-Str. 1 D-30625 Hannover Tel. +49 511 532-9574 |
|
From: DRC <dco...@us...> - 2015-03-17 20:17:26
|
Rebuild VirtualGL 2.4 from source with -DVGL_FAKEXCB=1. This will be automatic in the next major release, but since the issue was discovered after 2.4 went into beta, I felt it best to isolate the new code. Furthermore, libxcb is a more rapidly-changing API/ABI than Xlib or GLX, so an XCB faker built for one platform won't work on all platforms. We are going to have to develop some sort of dynamic loading mechanism for it, which will take some time. For now, please build your own custom version for whichever server platform you need to support. On 3/17/15 9:19 AM, Dr. Roman Grothausmann wrote: > Dear mailing list members, > > > Are there any known problems of VirtualGL with Qt5? > I'm working on a project (extensions to ITKSnap: > https://github.com/pyushkevich/itksnap/pull/1) which has just recently > moved to Qt5 and since then it seems that windows resizes do not work > properly any more (new regions in the program stay black or contain > artefacts, see *01.png) if the program is run with vglrun. Neither > resizing the main window with the mouse, nor maximize, nor > programmatical resizing works, this being the biggest problem, because > the program does so for specific modes, one of these is the extension I > work on. > If I compile and run the application on my desktop PC everything works > as expected (see *02.png). However, if run from a server with otherwise > functioning VirtualGL it does not work, nor if recompiled on the server. > It does work on the server for older versions of ITKSnap that build with > Qt4. > All together it gives me the impression the problem comes from the > combination of VirtualGL with Qt5. > > Many thanks for any help or hints how to solve this. > Roman |
|
From: Dr. R. G. <gro...@mh...> - 2015-03-23 11:41:03
|
Dear DRC, Many thanks for the quick reply and Your help. I got the chance now to reorganize and reboot our imaging server and trying Your suggestions. With -DVGL_FAKEXCB=1 programmatical resizes now work (using vglconnect or within VNC session), but resizing the Qt5 window with the mouse or using maximize still leads to artefacts. Do You have any idea what could be the reason for this? Many thanks for Your help. Roman On 17/03/15 21:17, DRC wrote: > Rebuild VirtualGL 2.4 from source with -DVGL_FAKEXCB=1. > > This will be automatic in the next major release, but since the issue > was discovered after 2.4 went into beta, I felt it best to isolate the > new code. Furthermore, libxcb is a more rapidly-changing API/ABI than > Xlib or GLX, so an XCB faker built for one platform won't work on all > platforms. We are going to have to develop some sort of dynamic loading > mechanism for it, which will take some time. For now, please build your > own custom version for whichever server platform you need to support. > > > On 3/17/15 9:19 AM, Dr. Roman Grothausmann wrote: >> Dear mailing list members, >> >> >> Are there any known problems of VirtualGL with Qt5? >> I'm working on a project (extensions to ITKSnap: >> https://github.com/pyushkevich/itksnap/pull/1) which has just recently >> moved to Qt5 and since then it seems that windows resizes do not work >> properly any more (new regions in the program stay black or contain >> artefacts, see *01.png) if the program is run with vglrun. Neither >> resizing the main window with the mouse, nor maximize, nor >> programmatical resizing works, this being the biggest problem, because >> the program does so for specific modes, one of these is the extension I >> work on. >> If I compile and run the application on my desktop PC everything works >> as expected (see *02.png). However, if run from a server with otherwise >> functioning VirtualGL it does not work, nor if recompiled on the server. >> It does work on the server for older versions of ITKSnap that build with >> Qt4. >> All together it gives me the impression the problem comes from the >> combination of VirtualGL with Qt5. >> >> Many thanks for any help or hints how to solve this. >> Roman > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for all > things parallel software development, from weekly thought leadership blogs to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > VirtualGL-Users mailing list > Vir...@li... > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > -- Dr. Roman Grothausmann Tomographie und Digitale Bildverarbeitung Tomography and Digital Image Analysis Institut für Funktionelle und Angewandte Anatomie, OE 4120 Medizinische Hochschule Hannover Carl-Neuberg-Str. 1 D-30625 Hannover Tel. +49 511 532-9574 |
|
From: Dr. R. G. <gro...@mh...> - 2015-03-23 11:48:39
|
On 23/03/15 12:40, Dr. Roman Grothausmann wrote: > With -DVGL_FAKEXCB=1 programmatical resizes now work (using vglconnect or within > VNC session), but resizing the Qt5 window with the mouse or using maximize still > leads to artefacts. Do You have any idea what could be the reason for this? I just found on http://svn.code.sf.net/p/virtualgl/code/tags/2.4/doc/index.html#hd0015 that vglrun has a +xcb option which is needed for this to work (an option vglrun -h does not list). With +xcb resizing the Qt5 window with the mouse or using maximize works as well. Cheers, Roman > On 17/03/15 21:17, DRC wrote: >> Rebuild VirtualGL 2.4 from source with -DVGL_FAKEXCB=1. >> >> This will be automatic in the next major release, but since the issue >> was discovered after 2.4 went into beta, I felt it best to isolate the >> new code. Furthermore, libxcb is a more rapidly-changing API/ABI than >> Xlib or GLX, so an XCB faker built for one platform won't work on all >> platforms. We are going to have to develop some sort of dynamic loading >> mechanism for it, which will take some time. For now, please build your >> own custom version for whichever server platform you need to support. >> >> >> On 3/17/15 9:19 AM, Dr. Roman Grothausmann wrote: >>> Dear mailing list members, >>> >>> >>> Are there any known problems of VirtualGL with Qt5? >>> I'm working on a project (extensions to ITKSnap: >>> https://github.com/pyushkevich/itksnap/pull/1) which has just recently >>> moved to Qt5 and since then it seems that windows resizes do not work >>> properly any more (new regions in the program stay black or contain >>> artefacts, see *01.png) if the program is run with vglrun. Neither >>> resizing the main window with the mouse, nor maximize, nor >>> programmatical resizing works, this being the biggest problem, because >>> the program does so for specific modes, one of these is the extension I >>> work on. >>> If I compile and run the application on my desktop PC everything works >>> as expected (see *02.png). However, if run from a server with otherwise >>> functioning VirtualGL it does not work, nor if recompiled on the server. >>> It does work on the server for older versions of ITKSnap that build with >>> Qt4. >>> All together it gives me the impression the problem comes from the >>> combination of VirtualGL with Qt5. >>> >>> Many thanks for any help or hints how to solve this. >>> Roman >> >> ------------------------------------------------------------------------------ >> Dive into the World of Parallel Programming The Go Parallel Website, sponsored >> by Intel and developed in partnership with Slashdot Media, is your hub for all >> things parallel software development, from weekly thought leadership blogs to >> news, videos, case studies, tutorials and more. Take a look and join the >> conversation now. http://goparallel.sourceforge.net/ >> _______________________________________________ >> VirtualGL-Users mailing list >> Vir...@li... >> https://lists.sourceforge.net/lists/listinfo/virtualgl-users >> > -- Dr. Roman Grothausmann Tomographie und Digitale Bildverarbeitung Tomography and Digital Image Analysis Institut für Funktionelle und Angewandte Anatomie, OE 4120 Medizinische Hochschule Hannover Carl-Neuberg-Str. 1 D-30625 Hannover Tel. +49 511 532-9574 |
|
From: DRC <dco...@us...> - 2015-03-23 20:13:17
|
On 3/23/15 6:48 AM, Dr. Roman Grothausmann wrote: > On 23/03/15 12:40, Dr. Roman Grothausmann wrote: >> With -DVGL_FAKEXCB=1 programmatical resizes now work (using vglconnect or within >> VNC session), but resizing the Qt5 window with the mouse or using maximize still >> leads to artefacts. Do You have any idea what could be the reason for this? > > I just found on > http://svn.code.sf.net/p/virtualgl/code/tags/2.4/doc/index.html#hd0015 > that vglrun has a +xcb option which is needed for this to work (an option vglrun > -h does not list). With +xcb resizing the Qt5 window with the mouse or using > maximize works as well. Yes, sorry about the bad game of Fizbin. The next release will make Qt5 support automatic, but it's going to require re-architecting the way VirtualGL handles the loading of symbols from the underlying libraries. |
|
From: Dr. R. G. <gro...@mh...> - 2015-03-24 14:49:45
|
On 23/03/15 21:13, DRC wrote: > On 3/23/15 6:48 AM, Dr. Roman Grothausmann wrote: >> On 23/03/15 12:40, Dr. Roman Grothausmann wrote: >>> With -DVGL_FAKEXCB=1 programmatical resizes now work (using vglconnect or within >>> VNC session), but resizing the Qt5 window with the mouse or using maximize still >>> leads to artefacts. Do You have any idea what could be the reason for this? >> >> I just found on >> http://svn.code.sf.net/p/virtualgl/code/tags/2.4/doc/index.html#hd0015 >> that vglrun has a +xcb option which is needed for this to work (an option vglrun >> -h does not list). With +xcb resizing the Qt5 window with the mouse or using >> maximize works as well. > > Yes, sorry about the bad game of Fizbin. The next release will make Qt5 > support automatic, but it's going to require re-architecting the way > VirtualGL handles the loading of symbols from the underlying libraries. No problem, it was just meant as a hint for others that might stumble into this problem. We are very grateful for VirtualGL, Your maintenance and Your support. Our whole server set-up would be hardly useful without it. Many thanks for that. One problem that I've observed with VirtualGL-2.4 (+XCB) is that the app crashes with [VGL] ERROR: in getGLXDrawable-- [VGL] 186: Window has been deleted by window manager if the window or a sub-window is closed with the closing-cross in the window frame created by the window manager. Can that be related to VirtualGL or XCB? This wasn't a problem before, nor is it when running the Qt5 app without VirtualGL. Thanks again Roman -- Dr. Roman Grothausmann Tomographie und Digitale Bildverarbeitung Tomography and Digital Image Analysis Institut für Funktionelle und Angewandte Anatomie, OE 4120 Medizinische Hochschule Hannover Carl-Neuberg-Str. 1 D-30625 Hannover Tel. +49 511 532-9574 |
|
From: DRC <dco...@us...> - 2015-03-30 04:16:27
|
On 3/24/15 9:49 AM, Dr. Roman Grothausmann wrote: > One problem that I've observed with VirtualGL-2.4 (+XCB) is that the app crashes > with > > [VGL] ERROR: in getGLXDrawable-- > [VGL] 186: Window has been deleted by window manager That isn't a crash. It's VirtualGL being nice and preventing a crash by catching the fact that the X window disappeared without the application explicitly calling XDestroyWindow(). In other words, it's a feature, not a bug. From VirtualGL's point of view, it actually is an error, because if the application never calls XDestroyWindow(), then VirtualGL never has a chance to shut down the virtual window instance (which, if using the VirtualGL transport, would also shut down the connection to vglclient.) In order to prevent it, the application should catch the WM_DELETE_WINDOW message from the window manager and shut down its window cleanly. See glxspheres.c in the VirtualGL source for an example of how to do this (although that source code shows how to do it with Xlib, not xcb, I assume it would be similar with xcb.) |
Thanks for helping keep SourceForge clean.
X