LWJGL Threading problem

Qudus · January 1, 2007, 10:50pm

hi

When I change the rendering thread for LWJGL I run into problems. Inside the rendering thread the following code is executed:


        if (renderingThread != Thread.currentThread())
        {
            /*
             * Sometimes it is necessary to remeber LWJGL, which Thread is is using ;-)
             */
            try
            {
                if (renderingThread != null)
                    Display.releaseContext();
                
                Display.makeCurrent();
            }
            catch (Throwable e)
            {
                e.printStackTrace();
            }
            
            renderingThread = Thread.currentThread();
        }

and this is the exception that crashes the game:



java.lang.IllegalStateException: From thread Thread[Thread-4,5,main]: Thread[main,5,] already has the context current
	at org.lwjgl.opengl.Context.checkAccess(Context.java:169)
	at org.lwjgl.opengl.Context.makeCurrent(Context.java:176)
	at org.lwjgl.opengl.Display.makeCurrent(Display.java:625)
	at org.xith3d.render.lwjgl.CanvasPeerImpl.renderStart(CanvasPeerImpl.java:652)
	at org.xith3d.render.lwjgl.CanvasPeerImpl.display(CanvasPeerImpl.java:1003)
	at org.xith3d.render.lwjgl.CanvasPeerImpl.render(CanvasPeerImpl.java:1104)
	at org.xith3d.render.Renderer.renderOnceInternal(Renderer.java:552)
	at org.xith3d.render.Renderer.renderOnce(Renderer.java:578)
	at org.xith3d.scenegraph.VirtualUniverse.renderOnce(VirtualUniverse.java:133)
	at org.xith3d.render.base.ExtXith3DEnvironment.render(ExtXith3DEnvironment.java:286)
	at org.xith3d.render.loop.RenderLoop.invokeRendering(RenderLoop.java:736)
	at org.xith3d.render.loop.RenderLoop.loopIteration(RenderLoop.java:757)
	at org.xith3d.render.loop.ExtRenderLoop.loopIteration(ExtRenderLoop.java:349)
	at org.stratagem.apps.Stratagem.loopIteration(Stratagem.java:176)
	at org.xith3d.render.loop.RenderLoop.nextIteration(RenderLoop.java:924)
	at org.xith3d.render.loop.RenderLoop.run(RenderLoop.java:960)
	at java.lang.Thread.run(Thread.java:595)
java.lang.NullPointerException
	at org.lwjgl.opengl.GL11.glRenderMode(GL11.java:2021)
	at org.xith3d.render.lwjgl.CanvasPeerImpl.renderStart(CanvasPeerImpl.java:725)
	at org.xith3d.render.lwjgl.CanvasPeerImpl.display(CanvasPeerImpl.java:1003)
	at org.xith3d.render.lwjgl.CanvasPeerImpl.render(CanvasPeerImpl.java:1104)
	at org.xith3d.render.Renderer.renderOnceInternal(Renderer.java:552)
	at org.xith3d.render.Renderer.renderOnce(Renderer.java:578)
	at org.xith3d.scenegraph.VirtualUniverse.renderOnce(VirtualUniverse.java:133)
	at org.xith3d.render.base.ExtXith3DEnvironment.render(ExtXith3DEnvironment.java:286)
	at org.xith3d.render.loop.RenderLoop.invokeRendering(RenderLoop.java:736)
	at org.xith3d.render.loop.RenderLoop.loopIteration(RenderLoop.java:757)
	at org.xith3d.render.loop.ExtRenderLoop.loopIteration(ExtRenderLoop.java:349)
	at org.stratagem.apps.Stratagem.loopIteration(Stratagem.java:176)
	at org.xith3d.render.loop.RenderLoop.nextIteration(RenderLoop.java:924)
	at org.xith3d.render.loop.RenderLoop.run(RenderLoop.java:960)
	at java.lang.Thread.run(Thread.java:595)
Exception in thread "Thread-4" java.lang.Error: java.lang.NullPointerException
	at org.xith3d.render.lwjgl.CanvasPeerImpl.display(CanvasPeerImpl.java:1068)
	at org.xith3d.render.lwjgl.CanvasPeerImpl.render(CanvasPeerImpl.java:1104)
	at org.xith3d.render.Renderer.renderOnceInternal(Renderer.java:552)
	at org.xith3d.render.Renderer.renderOnce(Renderer.java:578)
	at org.xith3d.scenegraph.VirtualUniverse.renderOnce(VirtualUniverse.java:133)
	at org.xith3d.render.base.ExtXith3DEnvironment.render(ExtXith3DEnvironment.java:286)
	at org.xith3d.render.loop.RenderLoop.invokeRendering(RenderLoop.java:736)
	at org.xith3d.render.loop.RenderLoop.loopIteration(RenderLoop.java:757)
	at org.xith3d.render.loop.ExtRenderLoop.loopIteration(ExtRenderLoop.java:349)
	at org.stratagem.apps.Stratagem.loopIteration(Stratagem.java:176)
	at org.xith3d.render.loop.RenderLoop.nextIteration(RenderLoop.java:924)
	at org.xith3d.render.loop.RenderLoop.run(RenderLoop.java:960)
	at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.NullPointerException
	at org.lwjgl.opengl.GL11.glRenderMode(GL11.java:2021)
	at org.xith3d.render.lwjgl.CanvasPeerImpl.renderStart(CanvasPeerImpl.java:725)
	at org.xith3d.render.lwjgl.CanvasPeerImpl.display(CanvasPeerImpl.java:1003)
	... 12 more

Any help would be appreciated. Thanks in advance.

Marvin

darkprophet · January 2, 2007, 1:12pm

The realseContext() call has to be made from the other thread that is no longer the rendering thread. The makeCurrent() call needs to be made in the new thread that wants the context.

Also, the thread that created the Display has the initial context, you would need to release the context after Display.create(…); if your rendering thread is not the same thread that created the Display.

DP

Qudus · January 2, 2007, 5:47pm

Thanks for the reply.

Why is all this necessary? Especially this releaseContext() thing. Why can’t an arbitrary thread pull the “render thread ownership” without the other thread release the context itself? This makes it really hard to abstract LWJGL.

Marvin

Qudus · January 2, 2007, 6:29pm

Got it. Thanks for the help :).

Well, for my (ignorant) feeling this is way more complicated than it has to be. JOGL does it without these threading issues and its even faster.

Marvin

darkprophet · January 2, 2007, 6:35pm

Those are all subjective feelings and are your opinion. Please keep these to yourself, no one needs to hear these sort of remarks. And for your information, JOGL does deal with them, but in a less transperant manner which makes it subjectively easier.

As for the “faster”, look at Jake2 benchmark results which reflect what a real life situation looks like, not just some random GL code written by amatures.

DP

Qudus · January 2, 2007, 6:58pm

Well, even if it is a subjective feeling, it should of high interest for any API designer. And if JOGL hides those threading problems from the user it is even more transparent ;).

Thanks for calling me an amateur ;D or Amos, who wrote the (real life) game, that I wanted to run with LWJGL. Just because the LWJGL API is worse than JOGL’s one, we are no anateurs when we (or I) complain about it ;).

Marvin

darkprophet · January 2, 2007, 7:14pm

Heh, if you had any idea how OGL worked, you wouldn’t have even thought about this let alone said it.

First of all, your comparing a released and very successful game to a game that I haven’t seen and im sure no one besides the inner circle of friends that Amos have will have heard about it. Are you seriously suggesting that them two are comparable? If you are…your living in coocooland

2nd of all, no matter what type of game it is, if the engine used to make the game doesn’t utilise OpenGL properly, nothing can save it. And well, we all know how Xith3D is doing these days in terms of performance…

I dont dislike you or Xith3D and im a big supporter of community projects. But you brought this upon yourself

Qudus · January 2, 2007, 7:31pm

Hey, I don’t want to compare these two games ???. I just made a very tiny comparison of LWJGL’s and JOGL’s API. I just don’t like these static methods all over the API. Of course this is subjective, but noone can seriously have anything against it, that I tell my opinion publicly :).

It’s not the game’s fault, but xith’s one (-> my fault ;)).

I’m working on it ;).

Well, of course, I brought this upon myself, if I use LWJGL’s API the wrong way. It’s just that I think, the lib could maybe handle it internally. That’s all. But certainly I don’t know LWJGL well enough to tell this ;).

Marvin

darkprophet · January 2, 2007, 7:37pm

You just negated what yourself!

You explicitly said that LWJGL is slower (which is your opinion, everybody is entitled to an opinion) and then you said that Xith needs work. How can you make a comparison between JOGL and LWJGL if your lib isn’t complete and doesn’t utilise both libs the same way?

Im finding it really hard not to take what you say with a grain of salt. But lets just cool this matter down and hope that the issue of mulithreading your app with LWJGL has been resolved with the releaseContext() method call

DP

Qudus · January 2, 2007, 7:45pm

I didn’t

We do utilize them the same way (as far as possible). The work, that needs to be done, is related to state sorting, but not to renderer API utilization.

Agreed (even if I don’t exaclty understand this “grain of salt” thing. But I guess it is something bad.). The issue is workarounded and doesn’t matter for Xith users. So it’s ok.

Marvin

Riven · January 2, 2007, 7:54pm

[quote]JOGL does it […] and its even faster
[/quote]
I just want to point out that the above is not just an opinion, so can you back it up with facts?

What exactly is faster anyway?
And I never had to deal with contexts at all in LWJGL, what makes you so sure LWJGL forgets it?

darkprophet · January 2, 2007, 7:59pm

Utlising both libs in the same way as possible isn’t being optimal to either libs. And IIRC, JOGL was used before LWJGL , this means your API was designed with JOGL so there is bias there…

But thats nor here or there lets just end the argument now.

DP

Qudus · January 2, 2007, 8:04pm

Well, any test case I ran was a bit (and only a bit) slower with LWJGL. Even though I heard from Windows users, that LWJGL performs better than JOGL on Windows.

Well I already removed the comment line about this forgetting thing from our project source. I just placed it there, because I was a bit angry, that one has to deal with it. LWJGL doesn’t forget it.

An example:

I have a loading screen, that renders information about loading progress. It is a lot faster, if it is only updated, when a new progress information is available. But the game runs in a constant loop in a separate thread, which I call the “actual render thread”. So when the actual render thread is started and wants to render the next frame, the contet needs to be switched. In this case I have to handle this context change in some way, which is not necessary (for me as the reedner API user) in JOGL.

Marvin

Qudus · January 2, 2007, 8:05pm

I guess, you’re right.

OK

eMKa · January 3, 2007, 4:29pm

@DP : yes the LWJGL renderer was implemented aftwards the JOGL one (in fact it was derived from the JOGL one). Following Qudus’s test on his Linux box, the current use of LWJGL by Xith3D leads to less FPS than the current use of JOGL by Xith3D. Period. About Xith3D performances, they have been improved greatly since jME benchmarks (with the Quake3 loader) : they’re now really similar. Also, the ones you call “amateur” have a right to try and make their own random hacks, as you do with volatile-engine (impressive screenshots, though I’m looking forward to being able to download something of your work.) And I think a little bit more of “savoir-vivre” would not do great harm to you. EOF.

darkprophet · January 3, 2007, 5:11pm

I never said you dont have the right to do anything. You can go and throw yourself off a bridge if you want; after all, you do have the right to do so.

2nd of all, the last place im going to learn any manners from is from forums. No offence, but you dont lecture me about good manners. Period. Afterall, If you are posting a topic about a particular problem in LWJGL, dont go mouthing off about LWJGL after you get the help…

3rd of all, i wasn’t bashing Xith3D at all, its a great effort and by all means carry on doing what you do. Its just at the moment, its not on par with other libraries out there and thats my opinion. You are ofcourse working towards making it better, but I believe you have a long way to go; again, thats my opinion and you can’t argue with opinions

PS. you do realise EOF stands for End Of File right ?

DP

Qudus · January 3, 2007, 5:26pm

Ah! That’s the point… Well, let me tell you, that I really appreciate the help, that I got here on the Forum. Thank you very, very much. It was fast and competent help. Mouthing off about the API design of LWJGL had nothing to do with that. I just wanted to tell you may opinion about the API design. And maybe I did it the wrong way.

Marvin

eMKa · January 3, 2007, 5:28pm

Run benchmarks again, with SVN Xith3D.
I’m afraid your “at the moment” correspond to early-2006. But we’re 2007, you know. On my crappy GF4 440MX SE I get 63.49 FPS with jME on the Q3 bench and 66.71 FPS with Xith3D-LWJGL… So you know Xith is just alright for me, “on par” enough.

Qudus · January 3, 2007, 5:30pm

jME is better for more high performance graphics cards and Xith for lower end cards… at the moment ;). That’s, waht renanse found out through his webstartable tests.

Marvin

eMKa · January 3, 2007, 5:31pm

Remember, that what you’re not used to often seems to you not as good as what you’re used to… Think about some experiments of Window users discovering Linux…

For my experiments between JOGL and LWJGL with my amateur-game I get pretty similar FPS. (And DP, remember I don’t work on the rendering code… so I just deal with high-level issues, hence the fact I’m probably an “amateur” doesn’t impact Xith3D use of JOGL or LWJGL. Though if you have some hints&tips of how LWJGL is different from JOGL, what can be often easily optimized, or so on, just tell us).