Silverfrost Forums

Welcome to our forums

Problem with swap_opengl_buffers in ClearWin+ OpenGl code.

20 May 2009 8:00 #4634

If a call is made thus:

call swap_opengl_buffers()

and there is not an open buffer (i.e. if there have been no calls to openGl drawing routines in the current window) then a fatal error results, and the program crashes.

I have a work around. This basically makes sure that the swap call only occurs in one place in a program and that a global logical is set true only when drawing has been initiated. Then this logical is tested immediately prior to the swap call. This works, but it is not elegant, and more seriously, makes restrictions on the design of the code.

Is it possible that the error generated could be made not fatal?

21 May 2009 7:15 #4636

I don't have a satisfactory answer to your problem.

TRAP_EXCEPTION@ and SET_TRAP@ can be used in some circumstances but maybe not for an exception generated in a third-party DLL. Recovery after using these routines is limited anyway.

22 May 2009 9:27 #4639

Peter,

As Paul has stated your error is generated from code not supplied by Silverfrost and thus he can do nothing to change this.

I had many bugs, crashes and general problems when I first started using OpenGL, as it is so different to any other graphics I had worked on previously (GDI, HPstarbase, Tektronix). I use glGetError to trap OpenGL specific errors, though I have never got the program to recover it does at least give me a more graceful exit.

I have found OpenGL to be intolerant to any bad data passed to it, thus I had to be sure that plot data was sanitised and the code robust. (plotting STL data created by CAD where a facet had almost zero area, evaluating the surface normal caused numerical problems for OpenGL and I had to filter out such stuff)

I use lists to store plot data, then call a routine that sets the background, displays all the defined lists and finally does the buffer swap at the end. Thus I have never experienced your particular problem.

Please login to reply.