LWJGL Forum

Programming => OpenGL => Topic started by: Qudus on January 12, 2008, 01:15:33

Title: Display.setTitle() hangs on Windows
Post by: Qudus on January 12, 2008, 01:15:33
hi

I tested my code on Windows, which works perfectly on Linux. And all of my apps simply hang when the Display.setTitle() method is called. I tried to call a display.makeCurrent() before even if the current thread is the correct one. But that didn't help.

Any thoughts?

Marvin
Title: Re: Display.setTitle() hangs on Windows
Post by: Matzon on January 12, 2008, 12:03:16
very strange?
Are you using multiple threads and stuff?
Do you have a simple test case ?
Title: Re: Display.setTitle() hangs on Windows
Post by: Qudus on January 12, 2008, 14:53:39
Quote from: Matzon on January 12, 2008, 12:03:16
very strange?
Are you using multiple threads and stuff?
Do you have a simple test case ?

Yes, I am using one thread for rendering only and one for everything else. But in my current case only the render thread is used.

Unfortunately I don't have a simple testcase. But I will try to create one.

Marvin
Title: Re: Display.setTitle() hangs on Windows
Post by: Qudus on January 12, 2008, 15:36:51
Hmm... I wasn't totally correct. The Display is created in the main thread and the Title is successfully changed right after the creation. Then the render thread is started. And from within this thread I change the title (to display FPS info). And no matter how I call releaseContext() and makeCurrent(), the method hangs. (And as I siad, on Linux it wirks perfectly without the makeCurrent()).

Does this help more?

Would you expect it to be necessary to call makeCurrent() before setTitle()?

Marvin
Title: Re: Display.setTitle() hangs on Windows
Post by: Qudus on January 12, 2008, 16:34:41
Here is a testcase, that demonstrates, that the rendering thread is (nearly) blocked, if it isn't the main application thread.

If a separate thread is used, it takes a few seconds until the window is even draggable. The thread itself is not blocked and renderings can be performed), but LWJGL doesn't respond anymore in terms of input: No Keyboard events, no mouse events and the window isn't closable anymore.

Just set the SEPARATE_THREAD constant to true to use the separate render thread way.

Thanks.

Marvin

PS: I am using LWJGL 1.1.3.
Title: Re: Display.setTitle() hangs on Windows
Post by: Matzon on January 12, 2008, 19:05:32
confirming and investigating...
Title: Re: Display.setTitle() hangs on Windows
Post by: Qudus on January 12, 2008, 19:46:33
Quote from: Matzon on January 12, 2008, 19:05:32
confirming and investigating...

Thanks.
Title: Re: Display.setTitle() hangs on Windows
Post by: Matzon on January 12, 2008, 21:54:15
Apparently the issue is that the Displays method should always be called from the thread that creates it. This is a win32 specific issue - and has to do with how Win32 works with messaging (sendmessage/postmessage and so forth). We cannot fix this (without incurring a lot of other nasty side effects which is even worse).

So basically, make sure that Display is only accessed by the Thread that created it. We may - in the future - (still dicussing this) add checks to make sure that you do not call the relevant methods from another thread than the creator.

You can read up on it here:
http://msdn2.microsoft.com/en-us/library/ms644928(VS.85).aspx
- notice the stuff that says:
QuoteThe system automatically creates a message queue for each thread. ... this message loop retrieves messages from the thread's message queue and dispatches them to the appropriate window procedures.
The problem is basically that setTitle posts a message to the calling threads message loop - NOT the one that created the window. If we post a message instead, then it would work - however the problem would occur in Display.update too - and we can't fix this, unless we introduce a message even queue - and then we're basically in Swing land with a specific Event Dispatch Thread, which we certainly do NOT want.
Title: Re: Display.setTitle() hangs on Windows
Post by: Qudus on January 12, 2008, 23:00:55
ok. Thanks for investigating the problem.

Marvin