Re: XForms: Problems with Mesa in a glcanvas object (2nd posting)

Eef Hartman (E.J.M.Hartman@math.tudelft.nl)
Thu, 25 Jun 1998 11:00:35 +0200 (METDST)

# To subscribers of the xforms list from Eef Hartman <E.J.M.Hartman@math.tudelft.nl> :

In a message to me Steve Lamont wrote:
> the very first glBegin in that. So the "state" of the OpenGL engine is
> such that it _seems_ to think it cannot draw anything yet.
> I must be missing something in the initialisation part, at least, that
> is what I'm thinking.

The thing I was missing is that it is an error to even CALL glGetError
within a glBegin/glEnd pair. You cannot get error codes in such a block.

So the glGetError itself generated the "GL_ILLEGAL_OPERATION" error code.

Found by tracing through the whole Mesa library (compiled staticly in
debugging mode).

Later I did find this restriction on glError on a PostScript man page I
found at SGI's ftp site.

Another thing I was missing is that XForms defaults to double buffered
GL, which means you MUST do an glXSwapBuffers before you can see the
picture, it was written into the background, NON-visible one of the two.

> The Canvas Window is mapped after the glx_init and glx_activate calls
> take place (see gl.c), so OpenGL should have its act together and be
> ready to draw at the point the Expose event arrives, I should think.

That is correct. The GL part now has no errors anymore.
Now to finish the program itself.

> Is GL_INVALID_OPERATION the only error in the error stack? According
> to the OpenGL blue book, you should call glGetError() in a loop:
>
> GLenum error;
>
> while ( ( error = glGetError() ) != GL_NO_ERROR )
> fprintf( stderr, "error = %d\n", error );

As the glGetError itself generates the GL_INVALID_OPERATION this leads
to an endless sequence of errors.

> If there are more errors in the stack, this might provide a better
> clue as to what's broken. One thing I really hate about OpenGL is
> that its diagnostic facilities are almost non-existant -- I'd would
> have really appreciated some facility for producing error messages at
> the point where the error actually occurs rather than having to grovel
> through a stack.

Mesa turns out to have a "MESA_DEBUG" environment option, which will print
an error msg by the routine that generates the error (it call a central
routine which checks for the enviroment variable first and then prints
the msg, with the routine name in it, which is an argument TO this routine).

As I said, the GL part of my program is now error free (for as far as errors
are checked, of course).

Just to inform you what the type of problems were, so you may recognize it
when it happens to you or others.

-- 
    \     /   /
   /#. # #-  #  /
  ## ## ## ##  ##
 # #   ## ##  ##
" "  #    ## ##
"."  ".   "./
TTTTTTTTTT  UU      UU    Eef Hartman, System Administrator
    TT      UU      UU
    TT      UU      UU    Delft University of Technology
    TT      UU      UU    Mathematics (Applied Analysis) dept.
    TT      UU      UU    Mekelweg 4, P.O. Box 5031
    TT      UU      UU    2600 GA  Delft, The Netherlands
    TT       UU    UU     e-mail : E.J.M.Hartman@math.tudelft.nl
    TT        UUUUUU      fax    : +31-15-278 7209
_________________________________________________
To unsubscribe, send the message "unsubscribe" to
xforms-request@bob.usuf2.usuhs.mil   or see
http://bob.usuf2.usuhs.mil/mailserv/xforms.html
XForms Home Page: http://bragg.phys.uwm.edu/xforms
List Archive: http://bob.usuf2.usuhs.mil/mailserv/list-archives/