Bindings for Wingdi.h and Linux/OS X alternatives

[httpdigest]

Somehow I was under the impression that LWJGL3 already provides all functionality to create an OpenGL context with platform-specific API, but I think there are some pieces missing.
For example, the functions and structs of Wingdi.h (for Windows), such as the ChoosePixelFormat function and the PIXELFORMATDESCRIPTOR struct.
I am trying to build a custom SWT GLCanvas, since SWT does not support creating OpenGL >= 3.0 contexts.
Can bindings to those be added please?

[Spasi]

These bindings were removed with d9c4a1b. We should re-introduce those that are needed for custom context management.

[httpdigest]

Absolutely! Or if you don't want to have it in core LWJGL3, then we can maybe also make a shared library / optional module out of these?

[Spasi]

Having them in core is fine. Creating a context using a foreign window handle should be available out of the box.

[httpdigest]

Cool! When those functions are reintroduced, having full SWT support with GL 3.0 contexts is a walk in the park. Just augmenting SWT's GLCanvas to use the additional context attributes.
I would provide the Windows implementation for it, and rely on someone else to do the Linux and OS X version, or just sneak over at GLFW how that is done.

[Spasi]

Bindings for wingdi.h are in 3.0.0b build 51. I think you're good to go on Linux/OSX with the existing GLX/CGL bindings, but let me know if you need anything else.

[httpdigest]

Thank you for reintroducing it! So far only GetDC and ReleaseDC is missing.
Those are in Winuser.h.

[httpdigest]

I used GetDC and ReleaseDC so far from SWT and now I have a problem that I think I did stumble on a year ago when creating a custom GL context with LWJGL3. The chicken-egg-problem with LWJGL3 that I cannot use wglCreateContext unless I already have a context.

Exception in thread "main" java.lang.IllegalStateException: No GLCapabilities instance has been set for the current thread.
    at org.lwjgl.opengl.GL.getCapabilities(GL.java:214)
    at org.lwjgl.opengl.WGL.getInstance(WGL.java:101)
    at org.lwjgl.opengl.WGL.wglCreateContext(WGL.java:126)
    at org.lwjgl.swt.win32.GLCanvas.<init>(GLCanvas.java:64)

How would I go about solving this without using GLFW?
I think LWJGL3 needs special entry points that omit loading all OpenGL function and extension pointers and requiring a full context being active, such as with wglCreateContext.
I can of course also just use SWT's native functions for this part (those are available anyways). That does work great. And only use LWJGL3 for the WGLARBCreateContext extended context attribute creation.

[httpdigest]

Sorry, I forgot that LWJGL3 even provides more lowlevel facilities to access native functions. I now resort to:

DynamicLinkLibrary lib = new WindowsLibrary("opengl32.dll");
long wglCreateContextAddress = lib.getFunctionAddress("wglCreateContext");
long context = callPP(wglCreateContextAddress, hdc);

Works like a charm without needing to initialize a full LWJGL3 context. :)
I would initialize the GLCapabilities once I have an extended context created via wglCreateContextAttribsARB.

[Spasi]

Better solution:

WGL wgl = new WGL(GL.getFunctionProvider());
long context = callPP(wgl.CreateContext, hdc);

[httpdigest]

Nice! :D
That works really nice. Now it's tidying up and a new SWTGLCanvas is ready.
I would also like to make the SWTGLCanvas cross-platform. SWT decided to basically completely duplicate/redesign all major classes for each platform.
That's why one always gets the full swt.jar with everything in it (there is no swt-common.jar) when downloading it for a specific platform, as sadly there are very few "common" classes.
I want to have runtime checks in a single class to decide which platform-specific functions to use.

[Spasi]

Changes in 3.0.0b build 52:

• Added the User32 class which provides GetDC and ReleaseDC.
• Renamed WinGDI to GDI32. I think it's cleaner to use the dll name, rather than the header in which the functions are defined (a single dll might export functions from multiple headers).

[httpdigest]

Thanks for the quick changes! I think we can close this issue now and track the progress of the new SWT GLCanvas in #107.