Latest build breaks awt event handling on linux

See this thread for a discussion about the problem: http://www.wurmonline.com/forum/viewtopic.php?t=4420
The “news window” is a swing window with a html component on it. It’s not modal.

I added an option for releasing the context each frame since I read about something like this earlier, but turning it on doesn’t help.

[quote] if I don’t press anything on it
its working… like the graphics are updating
I can see it raning now… I’m not on focus.
As soon as I send input
It freezes
like left click with mouse…
The client responds to me moving the mouse over the screen,
Like tall stone wall, and I see the blue highlight over models
but as soon as I click it freezes. […]
[/quote]
Great. Awesome. We’re supposed to go gold in two days.

ngh, wait, it seems like that option does actually work after all.
I’m hearing reports that when the game is releasing the context every frame, it doesn’t deadlock any more.

slightly frustrated bump

In JSR-231 beta 4 we introduced an optimization in the implementation of JOGL to not hold the AWT lock during makeCurrent/release pairs, only around the GLX operations each does. This optimization was done principally to enable simultaneous rendering to multiple screens on multi-head X11 setups. It assumes that there are no GLX tokens sent to the X server by normal OpenGL calls. Apparently this is not true and we found severe problems with ATI cards and less severe but still very serious problems with NVidia cards that forced us to disable this optimization by default in the nightly builds and in the forthcoming JSR-231 beta 5.

As I’ve said before I don’t think releasing the OpenGL context every frame should have any significant impact on any real-world application.

If you find you absolutely need this functionality I would suggest you consider using the LWJGL library rather than JOGL, since there is currently no way to robustly implement this optimization in the context of the AWT.

[quote=“Ken Russell,post:4,topic:27534”]
Except that this has been reported to blow up on some (ati, of course) cards with shoddy drivers. :wink:

Guess I’ll have to look into lwjgl again, then… Ideally supporting both.
I heard some rumor it was possible to make LWJGL use the same GL classes as jogl uses. That’d cut down on development time a LOT.

rummages

Not recently. Older drivers had some fairly serious memory leaks in some situations but I am pretty sure the current versions are all fine at least in this regard.

Yes, you can use JOGL’s GL class with LWJGL’s context management and vice versa. To do this in this particular direction, use LWJGL to set up the Display and once the OpenGL context is current use JOGL’s GLDrawableFactory to create an “external” GLContext, call makeCurrent() on it (which is basically a no-op), and start rendering. You’ll need to use LWJGL’s facilities to swap the buffers.

Ok, thank you. =)

I’ll make the “release context” option enabled by default after verifying it’s not significantly slower, then I’ll look into supporting both lwjgl and jogl.
The latter might be good for political reasons as well. :wink: