Revised SWT GLCanvas implementation

[httpdigest]

This is to track the progress of a new revised SWT GLCanvas.

Why do we want a new SWT GLCanvas?
Although the current implementation of org.eclipse.swt.opengl.GLCanvas is fully working with LWJGL3 it lacks many features that users desire:

• ability to create GL >= 3.0 contexts and GL >= 3.2 core/compatibility contexts (currently it only creates contexts via wglCreateContext under Windows)
• ability to specify multisampling (at least under Windows using ARB_multisample and WGL_SAMPLE_BUFFERS_ARB)

Properties of the new implementation
This implementation should build on top of #106.

It is desirable if the new GLCanvas implementation is a fully API-compatible drop-in replacement to the existing implementation. Ideally, to get an existing application working with the new class would just mean changing the package imports from org.eclipse.swt.opengl.* to org.lwjgl.opengl.swt.* (or something like that).
If in addition to that one wants to use the added functionality of the new GLCanvas class, this should be achievable via additional properties on the GLData structure, such as:

int majorVersion;
int minorVersion;
boolean forwardCompatible;
boolean core = true;
boolean compatibility;
boolean debug;

[oparisy]

Indeed this is a long-standing request with regard to SWT GLCanvas, as described by https://bugs.eclipse.org/bugs/show_bug.cgi?id=136514.

A code sample using JNA to address it was attached to this issue two years ago.

Clearly a higher-level, portable, LWJGL3-oriented solution would be great.

[oparisy]

Oh, looking at #105, I see that you have already walked most of that path ☺

[httpdigest]

Hey @oparisy. Yes, @Spasi was so anticipatory as to make that possible right away with LWJGL3. :)
I already have a Windows-working version of a GL context creation right now. Only need to tidy it up.

[httpdigest]

I had a look at that posted code from Florent in that Bugzilla issue.
The context creation in LWJGL3 should not assume that if a pixel format is unaccepted/unsupported this was due to a too high multisample count and then should not silently decrease that multisample count until the pixel format gets accepted. It might have had other reasons why that pixel format was not accepted.
I would prefer the client to be responsible for coping with an unsupported format and be informed (if possible) why the format was unaccepted. Also, the code assumes that WGL_ARB_pixel_format is available, which it may not. Old drivers are likely to require the respective Opengl32.lib functions to be used.
I try to take care of all those issues.

[httpdigest]

Hm... this is an insane PITA trying to both support everything (all WGL, ARB, ...) extensions for pixelformat and context creation including multisampling, as well as trying to keep context creation as separate from windowing as possible. Now I kinda know why GLFW chose to bind those two aspects together.
Currently, the platform-independent interface for a GLContext implementation looks like this:

long create(long windowHandle, long dummyWindowHandle, GLContextAttributes attribs);
boolean isCurrent(long context);
boolean makeCurrent(long windowHandle, long context);
boolean deleteContext(long context);

The second parameter dummyWindowHandle to create is what the proposed SWT code for multisampling does with the dummy Canvas. This is needed to create a pixelformat and a dummy context just to get a hold of wglChoosePixelFormatARB and to figure out whether multisampled pixelformats are supported or not.
I have it right now that this querying is done on that dummyWindowHandle and after that all is figured out, it will use the determined pixelformat and also immediately use wglCreateContextAttribsARB to create the real context (GL <= 3.0 or >= 3.0 or core/compatibility) on the real target windowHandle.
This all works this way iff the windowHandle and dummyWindowHandle actually use the same SWT Display and henceforth the same graphics card/driver, if different cards are associated with different displays when on a multi-GPU system. The caller has to ensure this and the new SWTGLCanvas does this.

[Spasi]

Why do you need a dummy window? You can create a dummy context on the real window, do some queries, then destroy it.

[httpdigest]

To create a dummy pixelformat. This is necessary on Windows, since pixelformats can only be set once on a window handle.

[httpdigest]

I committed a first working (alpha) win32 implementation of the new GLCanvas into:
https://github.com/httpdigest/lwjgl3-swt
It supports multisampled framebuffers and OpenGL 3.0 and 3.2 core/compatibility contexts, and has support for v-sync/swap-interval.

It is a drop-in replacement for SWT's GLCanvas. Just change the imports from org.eclipse.swt.opengl.* to org.lwjgl.opengl.swt.*. Also SWT's GLData can be used as is. The new version just adds additional fields (with sensible defaults) to support the new features. If the fields are unset, everything should behave like the current Eclipse's implementation.

[httpdigest]

The Windows implementation of the new GLCanvas is working well so far for me.

The pixel format and GL context creation is quite straight forward, although ugly as hell, because of a lot of duplicated error checking and undo code paths. This could of course be done more pretty. But you know: "First make it work, then make it better." :)

I am also certain that I've not yet run into all issues GLFW had to cope with and fix/workaround during its life, so there are sure to be bugs/quirks, which require testing on some Windows machines to find.
Currently, I could only get hold of two Windows 7 x64 machines with Intel HD3000, Intel HD4000 and Nvidia GK107 chips.
Playing with all sorts of configurations (singlebuffered vs doublebuffered, multisampling, swap interval, OpenGL 2.1 vs OpenGL 3.0 and 3.2 core/compatibility and forward-compatible, context sharing) seemed to work fine.

So, I would be happy if someone with a different Windows version (maybe Windows 10 or 8) or even Windows XP could test it on their machines.

Also, if someone wants to have support for more WGL extensions, such as OpenGL ES support or swapbuffer groups when rendering via multiple cards/video outputs with Nvidia Quadro's framelock/G-Sync, this can be added if requested.

The current implementation works for me and suits my usecases, so I won't put any more effort into the Windows implementation, unless someone asks for features or finds issues.
I'd also be happy if someone could provide the Linux and especially the OS X implementations, since I cannot test the latter.

[Bobo1239]

Appears to work fine on Windows 10 x64.
I just cloned the repo, ran Swt33CoreMsDemo, and played around with the values of the GLData structure.
Are there other things to test?

[httpdigest]

Thanks a lot for testing! Currently that's it for now. If you need anything, just tell. :)

[httpdigest]

The remaining GLCanvas method getGLData() to query the effective pixel format and context attributes is now also implemented. I successfully tested it on the machines I have available.
@Bobo1239 I'd be glad if you could test it too, though it should work just fine. :)
Also, since when you tested support has been added for the following:

• NV swap groups
• ARB robustness
• ARB robustness isolation
• NV delay before swap

[Bobo1239]

getGLData() as well as the the SharedContextsDemo work. Unfortunately, I'm still an OpenGL beginner and haven't worked with extensions yet so I can't help you test them without assistance.

[httpdigest]

Okay, I'm now on the Linux implementation. Since context creation and GTK window management is really strongly coupled in general and even more so in SWT, I will abandon the initial idea of decoupling context creation from windowing for SWT - it simply seems not feasible on Linux.
So, the design now got actually simpler, without any superfluous indirections. And everything now living in org.lwjgl.opengl.swt.

[Spasi]

The latest nightly build comes with OS-specific window creation bindings. Just a few basic functions are supported for now and more functionality will be added based on feedback. So don't hesitate to ask if you need anything.

[obidobi]

Awesome! Thanks for this one httpdigest.

I found this nice tool: http://synthclipse.sourceforge.net/
Your lwjgl3-swt will come in handy making similar stuff with lwjgl. Which of course is my preferred lib :)

[httpdigest]

Glad you like it. Write if you need anything.

Hmm... now that I think of it, especially great would be the possibility to change display mode in a fullscreen SWT Canvas. SWT cannot do that currently, only AWT can. But we don't want AWT, do we? :) Will add that to lwjgl3-swt with a little help from @Spasi .

[LWJGL], which of course is my preferred lib :)

Give it a star, then. :)

[httpdigest]

Progress and further issues should be tracked on the lwjgl3-swt repository.