Re: [Opensg-users] glutMainLoopEvent, threads and what not

[Bart K. <bar...@gm...>]

Hi
> Just a theory:
>
> If the same thread that does this call is responsible for handling the 
> win32-message loop, it might be a problem. However, that would suggest 
> freeglut has a bug.
>
Yeah, I somehow don't think that is the case. Especially since it does 
work when the other plug-in (a QT based GUI displaying some info and a 
splash screen) is running. That is what's bothering me about this. It's 
not a "It works in debug mode, but doesn't in release" kind of problem. 
I really have no clue what the other plug-in adds that makes my plug-in 
work. Like I said before, they are totally unrelated.... But okay, I 
will continue to hunt.
> One could perhaps post a WM_PAINT message before calling the blocking 
> function and see what happens. It might fix it (on the grounds that 
> the message is in the queue and thus allows the function to return).
>
Well, I don't know a lot about the underlying calls in windows, but 
RedrawWindow is called like this by freeglut:
        RedrawWindow(window->Window.Handle, NULL, NULL, RDW_NOERASE | 
RDW_INTERNALPAINT | RDW_INVALIDATE | RDW_UPDATENOW
        );

RDW_INTERNALPAINT would suggest to me that a WM_PAINT message is being 
posted regardless of whether or not the window needs to be updated.

All in all I'm expecting it to be more a threading issue where one of 
the threads is in a lock for some reason. This is just a feeling though. 
I haven't been able to hunt down the responsible thread.

Greets, Bart.