From a.janke at gmail.com Tue Nov 1 11:00:36 2011 From: a.janke at gmail.com (Andrew Janke) Date: Wed, 2 Nov 2011 01:00:36 +1000 Subject: [MINC-development] GLUT colours In-Reply-To: <3E5A7A72-A770-451E-8A67-8D2227795460@phenogenomics.ca> References: <3A53A56C-954C-4AB8-856A-AF1F9B6E280F@phenogenomics.ca> <3E5A7A72-A770-451E-8A67-8D2227795460@phenogenomics.ca> Message-ID: Hi Jason (And others), > I was rebuilding all the MINCy goodness on OS 10.7, and am running into some > fun psychedelic colours with Display and register (see attached). Anybody > have any hints about where to look to solve this? I remember a message from > Jim a few months/years ago which appeared to suggest that this issue was > somehow tied into MINC versions, supposedly patched in 2.0.19. I'm using > 2.1, in case that is indeed the issue; if anyone remembers where in the MINC > codebase that colourful output was created I can look to see if it's still > there or has somehow returned ... As Giovanna mentioned it seems to be a chance in freeglut that (in my experience) causes some conflict with nvidia drivers. At least this is the problem I see on the one Ubuntu system on which I can make this happen. If I then remove the nvidia driver and use nv, the problem goes away. You'll also find that other GLUT packages are also having this issue "out there" via our friend google. To test what is going on with your machine (this bug seems to have multiple incarnations) try this little bit of code: #include /* compile with: gcc -o test test.c -lglut */ void display(void) { glClear(GL_COLOR_BUFFER_BIT); glFlush(); } int main(int argc, char **argv) { glutInit(&argc, argv); glutCreateWindow("test"); glutDisplayFunc(display); glutMainLoop(); return 0; } On some systems this will result in a pretty colours others a black background (as would be expected). Some also have this little bit of test code whinging "Could not get requested colour_map_mode(0), got(1,256)". So, that's where I've got with this so far! ie: nowhere really given that I can reproduce the buggy behavior without MINC! My only thought for this is to finish off/trim down viewnup and put the point based registration code into it as it doesn't seem to suffer this issue. So that's what I've been doing in the last few weeks as this one doesn't seem to want to go away. here's hoping you find some magick little hack to get around this. :) a From assemlal at cim.mcgill.ca Wed Nov 2 16:53:37 2011 From: assemlal at cim.mcgill.ca (Haz-Edine Assemlal) Date: Wed, 02 Nov 2011 20:53:37 -0000 Subject: [MINC-development] GLUT colours In-Reply-To: References: <3A53A56C-954C-4AB8-856A-AF1F9B6E280F@phenogenomics.ca> <3E5A7A72-A770-451E-8A67-8D2227795460@phenogenomics.ca> Message-ID: <1320267143.2330.13.camel@talos> Hi Andrew, It seems that Display 1.4.x is not affected by this issue. The differences with Display 1.5.x are mainly in the file Graphics/GLUT_windows/glut_windows.c. It looks like that v1.4.x was aware of this bug and found a hackish way to go around it. In particular, it includes its own freeglut_std.h and glut.h. Display 1.5.x does the things properly but then relies on a correct implementation of GLUT in the drivers. Is there any significant feature or improvement from Display 1.4.x to 1.5.x? Best, Haz-Edine On Wed, 2011-11-02 at 01:00 +1000, Andrew Janke wrote: > Hi Jason (And others), > > > I was rebuilding all the MINCy goodness on OS 10.7, and am running into some > > fun psychedelic colours with Display and register (see attached). Anybody > > have any hints about where to look to solve this? I remember a message from > > Jim a few months/years ago which appeared to suggest that this issue was > > somehow tied into MINC versions, supposedly patched in 2.0.19. I'm using > > 2.1, in case that is indeed the issue; if anyone remembers where in the MINC > > codebase that colourful output was created I can look to see if it's still > > there or has somehow returned ... > > As Giovanna mentioned it seems to be a chance in freeglut that (in my > experience) causes some conflict with nvidia drivers. At least this is > the problem I see on the one Ubuntu system on which I can make this > happen. If I then remove the nvidia driver and use nv, the problem > goes away. > > You'll also find that other GLUT packages are also having this issue > "out there" via our friend google. To test what is going on with your > machine (this bug seems to have multiple incarnations) try this little > bit of code: > > #include > > /* compile with: gcc -o test test.c -lglut */ > > void display(void) { > glClear(GL_COLOR_BUFFER_BIT); > glFlush(); > } > > int main(int argc, char **argv) { > glutInit(&argc, argv); > glutCreateWindow("test"); > glutDisplayFunc(display); > glutMainLoop(); > return 0; > } > > On some systems this will result in a pretty colours others a black > background (as would be expected). Some also have this little bit of > test code whinging "Could not get requested colour_map_mode(0), > got(1,256)". > > So, that's where I've got with this so far! ie: nowhere really given > that I can reproduce the buggy behavior without MINC! > > My only thought for this is to finish off/trim down viewnup and put > the point based registration code into it as it doesn't seem to suffer > this issue. So that's what I've been doing in the last few weeks as > this one doesn't seem to want to go away. > > here's hoping you find some magick little hack to get around this. > > :) > > > a > _______________________________________________ > MINC-development mailing list > MINC-development at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development