The SGIs seem to have both double buffered and single buffered visuals.
For some reason Tkinter seems to be picking up the single buffered one
when the SGI OpenGL is used, but the double buffered one when Mesa is
used. I haven't a clue why that might be the case.
Wayne
On Thu, 28 Oct 2004, Borlan Pan wrote:
> I installed the newly released Mesa-6.2 and it seems to work with that now.
>
> Borlan
>
> Wayne Boucher wrote:
>
> >Hello,
> >
> >After a bit of grief (just finding an SGI with a compiler on it) I can see
> >what is causing the problem but the "solution" so far is not complete.
> >
> >In order to know what "drawable" (OpenGL jargon) is being drawn in, the
> >Python widget gets passed to the C world and a "context" (more OpenGL
> >jargon) is created, and to do that you need a "visual" (more OpenGL
> >jargon). Then when you want to draw into that drawable you make a call to
> >glXMakeCurrent() with that drawable and context as arguments. The
> >glXMakeCurrent() man page says:
> >
> >"BadMatch is generated if drawable was not created with the same X screen
> >and visual as ctx. It is also generated if drawable is None and ctx is not
> >None."
> >
> >I checked explicitly and drawable and ctx (the context) are both not None.
> >And there is only one screen. So it looks like the drawable was not
> >created with the same visual as ctx. Like I said, the drawable comes from
> >the Python world and which visual it is created with is a bit beyond our
> >control. The visual in the C world is created as follows (this is in the
> >function new_gl_handler() in ccpnmr1.0/c/ccpnmr/global/gl_handler.c):
> >
> > visual = glXChooseVisual(display, DefaultScreen(display), dblBuf);
> >
> >where dblBuf is defined a bit above that line as:
> >
> > static int dblBuf[] = {GLX_RGBA, GLX_DOUBLEBUFFER, None};
> >
> >The first two arguments mean:
> >
> > GLX_RGBA: If present, only TrueColor and DirectColor visuals are
> >considered. Otherwise, only PseudoColor and StaticColor visuals are
> >considered.
> >
> > GLX_DOUBLEBUFFER: If present, only double-buffered visuals are
> >considered. Otherwise, only single-buffered visuals are considered.
> >
> >If I use dblBuf as is, or if I remove either but not both of those
> >arguments, then I get the BadMatch problem. I am not too bothered about
> >GLX_RGBA but I am about GLX_DOUBLEBUFFER. If I remove both, so have:
> >
> > static int dblBuf[] = {None};
> >
> >then I do not get the BadMatch problem. So I end up being able to display
> >contours. Only the whole thing does not really work properly: the
> >background is black instead of white, the crosshair does not get
> >refreshed (so the xor mode is not working), etc. (This is probably
> >because the Python code pretty much assumes double buffering is working.)
> >So this is not sorted yet.
> >
> >Is there double buffering on these oldish SGIs? I thought there was, but
> >perhaps not.
> >
> >Wayne
> >
> >On Tue, 26 Oct 2004, Borlan Pan wrote:
> >
> >
> >
> >>Unfortunately, neither GL_FALSE and GL_TRUE help.
> >>
> >>Borlan
> >>
> >>Wayne Boucher wrote:
> >>
> >>
> >>
> >>>Hello,
> >>>
> >>>I've done a bit of a trawl on google and as usual the question appears a
> >>>few times but not the answer. In particular already back in 1999 someone
> >>>had this problem with exactly the same note about it working on another
> >>>display:
> >>>
> >>>http://oss.sgi.com/projects/performer/mail/info-performer/perf-99-08/0000.html
> >>>
> >>>Someone in 2002 also had this kind problem trying to use another display
> >>>(so even worse than you are having, but the "X Error of failed request"
> >>>was different):
> >>>
> >>>http://oss.sgi.com/projects/performer/mail/info-performer/perf-02-01/0004.html
> >>>
> >>>and said they had tried xhost to sort this out but it did not.
> >>>
> >>>Now recently we changed one of the parameters in one of the first OpenGL
> >>>calls because it was causing the non-drawing of contours on Linux boxes
> >>>using native Nvidia OpenGL drivers. You could try changing this back to
> >>>see what happens. So in ccpnmr1.0/c/ccpnmr/global/gl_handler.c in the
> >>>function new_gl_handler() there is a line:
> >>>
> >>> context = glXCreateContext(display, visual, None, GL_FALSE);
> >>>
> >>>and you could change this back to:
> >>>
> >>> context = glXCreateContext(display, visual, None, GL_TRUE);
> >>>
> >>>(it's commented out in the text above the current version). Then type
> >>>"make" and "cd ../analysis" and "make" and try running Analysis again.
> >>>
> >>>If that works then we can try to put both variants in (somehow). (My
> >>>guess is that it will not solve it but you never know.)
> >>>
> >>>Wayne
> >>>
> >>>
> >>>
> >>>
>
|