Support for multiple contexts

[princec]

What's the score with multiple contexts these days? I have a need to use more than one display (two separate AWT canvases, as it happens), and I suddenly realised our commitment to games and simplicity here as finally turned around and bitten me on the arse.

Cas

[spasi]

I'll do some tests locally and let you know how long it will take to implement this and if it can be done without disrupting the API (or implementation) too much. If we're talking strictly about GL contexts/windows, it isn't a big deal, we already have nice support for multiple contexts. The problem is the input stuff. In the current implementation Display = keyboard = mouse, with multiple Displays we'll need to decouple the Display and input stuff and provide some new means to make it work together.

[Kai]

I use multiple (shared) contexts for quite some time now (using AWTGLCanvas) and have yet to find any trouble with it.
What is it that causes you (princec) trouble with it?
Though I am really happy with AWT, I really would like to know what the rationale behind using the native Display class is.

[kappa]

yeh, we've kinda looked at this problem on #lwjgl a few times, multiple contexts have been requested alot and it seems like we'll have to move away from a static api to support them (unless we somehow use different class loaders)

[princec]

I suggest not touching the existing Display APIs at all. Multiple contexts are really an AWT thing too, so there's no need to involve the LWJGL Mouse and Keyboard, which also are pretty much specifically designed to work exclusively with Display. This is what the L bit in LWJGL was all about - just making a simple platform for the 99% of common usage.

Nowadays though we're looking at slightly more sophisticated usage and with the probable demise of JOGL something needs to take up the challenge.

I hadn't actually looked at AWTGLCanvas lately - for some reason I'd been under the impression it was "deprecated" in favour of the less-flexible Display.setParent(). I'll give it a look now - it might possibly be all that's really needed.

Cas

[kappa]

AWTGLCanvas was depreciated, at one point it was going to be removed (due to being unreliable and buggy), only reason it was left in place was that there was no other way to have multiple lwjgl contexts. The lwjgl AWTMouse and AWTKeyboard stuff was deleted (was crappy anyway).

[spasi]

I had some free time yesterday and hacked Display a little bit... It kinda works, but I'm afraid it will take several changes and loads of testing to cover everything. My approach was very simple: I simply added instance methods for every public static method in Display, added a private instance of Display that the static methods use (so we remain API compatible), added some hackery to fix little issues and disabled input to focus on Display stuff alone (with org.lwjgl.opengl.Display.noinput=true). The result was that I could create 2 JFrames and add 2 different Displays in their Canvases, with a different thread rendering in each JFrame. It can work in a single thread too, with makeCurrent. Anyway, it bombs after a few seconds (rendering freezes with no exceptions thrown), I think processMessages() is to blame, but I think we can make it work.

The problem is that I'm not at all familiar with the windowing system event stuff and the mouse/keyboard code. I haven't used LWJGL inside Swing either. I will need help if we decide we have to do this.

Could someone post a comparison of using AWTGLCanvas and Display.setParent? What are the differences, pros and cons of each approach? How do people handle input when using (one or more) AWTGLCanvas(es)?

edit: I want Elias back...

[princec]

The AWTGLCanvas is working just great for me, and is probably the way we should go for general AWT integration (hacked to use your new display hackery). Display was always meant to be a quick and dirty "just get it working" solution for games programmers. Each Display should probably have its own processMessages thread if you're going to do it like that but I have a feeling it's meddling with the unmeddlable. Perhaps the effort's better spent in exposing more GLContext stuff on AWT Canvases?

Cas