Rendering Problem with OpenGL OR Thread OR C++ OR WIN32

Part of a program i'm developing has an OpenGL interface. I originally wroted the program
as non-threaded, but have decieded to add a thread to repeatedly render the GUI, allowing
rendering while I block waiting on a comm port. However when I add a loop in a thread which
calls the rendering function, it won't render, but If I call the rendering function from the main
message loop it will. (I've more code as required)
[IN THE CODE BELOW wgui is a global (only 1) instance of the class WirmedGUI)]
[IN THE CODE BELOW the problem is not caused by equalizeBuffers();]

------------- MESSAGE LOOP CALL ------------------
      //Enter the message loop
            //Poll for waiting messages
            while(PeekMessage( &lpMsg, NULL , 0, 0, PM_REMOVE) && !done)
                  if (lpMsg.message==WM_QUIT) done=true;      //Check for the end condition                  
                  TranslateMessage( &lpMsg );
                  DispatchMessage( &lpMsg );
            //trigger an update in the GUI
            wgui.updateImage(false);              //<---------------------------------------------------THIS CALL WORKS

------------- THREAD LOOP CALL ------------------
//Rendering Thread Primary Function
DWORD WINAPI WirmedGUI::ThreadFunc( LPVOID lpParam )
      //While were not done
            printf("THREAD RENDER\n");
            //Update the image
            wgui.updateImage(false);          //<-----------------------------------------------------THIS CALL DOESN'T WORK
      return 0;

------------- THREAD LOOP CALL ------------------
//Update internal scene representation, call DrawGLScene (to execute the GL commands), and revaildate the display.
void WirmedGUI::updateImage(bool justgui=false)
      ValidateRgn(hWnd, NULL);
      printf("RENDER [hWnd:%i, hDC:%i] > ",hWnd,hDC);
      equalizeBuffers(); //Make sure the frame buffers are the same (prevents flickering of partially updated images      
Who is Participating?
AlexFMConnect With a Mentor Commented:
wgui.updateImage(false);          //<-----------------------------------------------------THIS CALL DOESN'T WORK

What does this mean "doesn't work"? Function is not called, ot screen is not redrawn? Do you see printf output?

However, I think it doesn't matter. Main thread should draw the screen, and COM port should be handled in the worker thread. This is standard program design, I suggest you to change your program accordingly. Drawing on the screen from worker thread creates a lot of problems.
Falcon_ZeroAuthor Commented:
The result varies from computer to computer. On one PC i get very fast flickering 1inch bands of the OpenGL scene against the previous background (Desktop in this case) on another, I just get a black screen, which leads me to suspect a problem with OpenGL or something causing a problem which is manifest by OpenGL.
As for placing the comm functions in a worker,  I was really trying to avoid having to change the architecture of the program, which is already 10k lines long. The multithreaded side of things is in responce to a change in requirements. If I can make the above code work, thats the extent of the multithreading required. (Only ever 2 threads for this program (main & gfx).)
I agree that its better to have the gfx in the main thread, but I since I'm trying to change this with the minimum of rewriting i'll take a beating for bad style, but i'll also get
the praise for making the target date.
Falcon_ZeroAuthor Commented:
Well, I guess I'll have to bite the bullet on this one. I'm no closer to a solution, so I'll just have to rewrite the com side of things as multi-threaded.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.