Solved the multithread prob…
But here is some weirdness that I hope someone can give me a clue on…
2 threads are running and each are suppose to update a separate drawing area.
When both threads kick off at the same time…the call to glXMakeCurrent, each being a call in a separate thread, takes the XtWindow of the drawing area and applies it to the other drawing area. So…in short…I have 2 different contexts drawing to the same drawing area (which is legal…but undesirable).
Am I being clear? 
What do you mean ? Haven’t you forget to update your viewport ??
viewport?
Sorry for being so stupid
Sorry…now I just figured out what ya mean…
glViewPort yes?
Never use that…I am just trying to draw a line of pixels.
glDrawPixels(getWidth(), 1, GL_COLOR_INDEX, GL_UNSIGNED_BYTE, checkImage);
The drawing area was created with XtVaCreateManagedWidget(“m_glxarea”, glwMDrawingAreaWidgetClass,
_frame, GLwNvisualInfo, m_pVisInfo, NULL);
But it seems as though the server is getting confused by a multi threaded call to MakeCurrent…even though the threads mutex their calls to the draw routine…which is wher th make current call is made.
yes I meant glViewport. From what you wrote, this is what I understood.
I don’t know xt, so I can’t know what the function really does, neither what it allows or disallows. For X and multithreading I simply use the X lib, which is not so hard to program with, neither to understand.
Also, if you could elaborate what you exactly mean with drawing area, what do you expected and what do you get, it would really help.
I have 2 objects that each have a drawing area (drawing area created as above). This is in Solaris 8 using opengl 1.3.
So a drawing areas from what i understand is a xmdrawingareadwidgetclass which = glwMDrawingAreaWidgetClass…
So the following is what I would expect to happen.
Each thread has an object that contains a drawing area. So when MakeCurrent gets called I would expect the XtWindow of the drawing area to be assigned as the currentdrawable for the assigned object’s context for that thread.
But what I see going on is that 1 thread comes in and calls MakeCurrent. Now maybe the next thread kicks off an preempts the makecurrent call and makes its own makecurrent call. I am seeing now that both threads are assign the XtWindow of the second makecurrent call. So what happens is that I have 2 different sets of data being drawn to the same window.
Clearer?
So you want 2 threads to draw into their own window, but what you have is the 2 threads that draw into the same second window.
From that point, glViewport won’t help you correct your problem.
Your suggestion about your second thread that preempts the first one make me think that you might have done some mistakes in your synchronization. Only one context can be active at the same time for a given thread. So ‘maybe’ your second thread activates the same context ? (which should not happen since you use 2 distinct windows). I guess the problem can be from that point. So try to check those 2 possibilities.
Also I can suggest you to read more doc about Xt or, as I stippled in a previous post, to switch to the X lib directly. Generally functions or structures have specific behaviors when on multithreading.
A bit clearer, yes.
See…the wierdness is that the first thread comes into the draw routine, starts to call MakeCurrent… gets preempted…the second call comes in finishes Makecurrent…but the first thread now has the XtWindow of the second thread. So now…1 window in the second thread is updated by 2 context in different threads.
So…I put a global mutex around the MakeCurrent to ensure that the MakeCurrent call completes to avoid interruption. However…I still see the same behavior.
Verified the synchronization is working.
But there should be no sync issues each thread updates their own window.
If it was a 1 active context per window thing then I should see a glx error somewhere (which there is none).
So I’ll see about getting more info on the Xlib stuff.