The snag seems to be drawing the map areas. Those screenshots don't show it, but there can be multiple maps open at a time, possibly open next to each other (ie. multiple visible at the same time). Currently what I do is use Slick + LWJGL to share a single opengl context, then actual display that via multiple AWT Canvas objects (via LWJGL's Display.setParent()), which in turn are embedded in a SWT Composite via SWT's "awt bridge". This is pretty ugly but on windows it actually works well.

Unfortunately the swt/awt bridge doesn't seem to be properly implemented on non-windows platforms, and on OS X it's Just Plain Broken (tm). I'd really like to get it working there, so I'm looking for ways around this.

All I'm after is multiple visible canvases which I can draw onto via OpenGL. I don't care whether the underlying components are SWT or AWT, I don't care if it's via LWGJL, Jogl or org.eclipse.swt.opengl, and I don't care if it uses one context or multiple contexts.

2. As for 1, but with some kind of caching for textures so they get loaded and unloaded on demand (but still duplicated across contexts) to try and keep memory usage reasonable. Would probably hurt performance though.

3. Somehow create a single off-screen opengl context and do all texture loading and rendering to this. Copy the final pixel data to a non-opengl swt canvas to display multiple views at the same time.

I don't know how Slick works, but on semi-new macs (intel based, nvidia 8600+) I've been able to create and share contexts between multiple JOGL GLCanvas's and PBuffers. It's pretty easy to say whether or not to share (just pass the shared context into the constructor), but the support isn't guaranteed on all platforms and doesn't always let you know, either.

I don't know how Slick works, but on semi-new macs (intel based, nvidia 8600+) I've been able to create and share contexts between multiple JOGL GLCanvas's and PBuffers. It's pretty easy to say whether or not to share (just pass the shared context into the constructor), but the support isn't guaranteed on all platforms and doesn't always let you know, either.

This is largely what I'm currently doing with LWJGL and Slick (sharing a single context between multiple canvases). The problem is that to embed the LWJGL canvas within the SWT app I've got to use the AWT<->SWT bridge, which doesn't appear to work on mac. Switching to Jogl wouldn't help as I'd still have to use the bridge to embed Jogl's AWT canvas.

What is your rendering scheme? Do you only render when necessary? or is it a continuous update type deal. I would think that if it's the first case and because it's an editor, performance is not such a big issue so you could get away with #3.

What is your rendering scheme? Do you only render when necessary? or is it a continuous update type deal. I would think that if it's the first case and because it's an editor, performance is not such a big issue so you could get away with #3.

It's event driven, so yes it should be only when necessary. The one thing I worry about with approach 3 is that it'll make scrolling and dragging less responsive (possibly to the point of being unusable?). I guess I should probably do a quick prototype and see what the performance is like.

I never was able to fix this at the time, but now I'm looking into writing another swt/rcp editor and looking into the same problem, and google pointed me right back at my original problem.

Things have moved on a little, and now there's a proper swt gl canvas. Interestingly in the GLData init object it's got a param for an existing canvas so it can share the context. This looks like it was added in the Galileo release when the swt/osx end was overhauled to better support cocoa.

With a bit of luck this will do exactly what I was trying to do originally...

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org