lwjgl with JPanel

Started by gmseed, November 03, 2011, 21:31:04

Previous topic - Next topic

PrintIn3DNow

OK, so I got that figured out for the most part. By doing the setParent(...) and create() inside the other thread, I was able to receive the mouse updates while allowing the UI to do its work of navigating the file tree. I say 'For the Most Part', because I'm still having a few issues. I'm not sure if these are more LWJGL related or thread related, but it seems like there's a catch-22 when working with the Display.

Under what circumstances can you query the state of the Display? Can you always call isCreated? At what point does isCurrent() become valid? After destroy() is called, are there any remnants?

CodeBunny

What errors are you experiencing?

When you call destroy on the display, that's it. Don't call LWJGL any more.

PrintIn3DNow

Hi CodeBunny, I kept working at it, and I have it solved, at least in terms of execution. But I'm a little unsatisfied. Maybe confused. When I was first trying to code the second thread, I was still doing some initialization stuff in the main UI thread, and having the 'gameloop' thread start up when a file was actually selected for previewing. Eventually I discovered that I had to call 'makeCurrent()' in the second thread.

So then I started checking for isCurrent() in the second thread, and call makeCurrent() if not. (Eventually I discovered I had to release it in the first one.) I was often surprised at how long the stacktrace would be. Anyway, I kept having problems with input, and did the whole 'moving everything into the thread'. Then I started getting some null pointer exceptions. Eventually I figured out that they were happening when I called isCurrent(). I think what it is, is, you can't check the status of the current context without calling .create(). I was trying to make sure the display hadn't already been created and that I was allowed to makeCurrent() when there was nothing to make current. It seems to me that if the display isn't created, isCurrent should just return false and makeCurrent should just return true. Why raise an exception? This is a victimless crime.

I can't remember exactly, but I think I also had a problem when I tried calling isCreated() from the second thread. I think, if it was created, I got a context exception for reading it, and if it wasn't created, I got an exception for checking isCurrent(). It might have been something like that. At first, I couldn't figure out how to deal with it. Now I just don't call any Display functions at all in the main thread, and I assume the second thread is making sure it's cleaned up. I think it could be better.

Also, I wanted to make sure that the UI thread did not have the context blocked, so I was trying to call releaseContext() and it was generating exceptions too. Again, it seems to me, if there's nothing to pass around anyway, it may as well let the threads think whatever they want, but who am I to say. I see in the source code that the Display class works directly with the Drawable object. I suppose I could add a test for null in the source, read one of the tutorials on how to recompile everything, and go from there. That would make updates a total pain though, so I doubt if I'll be doing that.

Anyway, thanks for the thread tip, I think I'll eventually get it to work right. I think my biggest problems now are Java/Thread related, not LWJGL specifically. I have a sync'd method in my runnable class to tell me when to stop. The problem is that I can't call wait() or join() on the display thread. I can't figure out how to specify the UI owns the Display thread. When I call the wait or join, it throws exceptions about ownership. yield() seems to work, but it feels clumsy.

Take care,
Dan B.

CodeBunny

Okay, then, good luck. From what I understand, if you limit every call involving LWJGL (including, I think, loading libraries) to a single thread, you shouldn't have ownership/isCurrent problems, so maybe you should make sure that everything is in that second thread.