[CLOSED] Features in JGLFW (LWJGL 3)

[EnergyRay]

Hello all!

While messing around with LWJGL 3 and learning to use JGLFW, I've discovered a lack of certain features in it. I just want to list some things that should be added/changed to make things more intuitive.

• JGLFW is missing some functions compared to the actual GLFW, for example, "getFramebufferSize", and "setWindowTitle" (I couldn't find them at least).
• While JGLFW is more object-oriented, the GLFWobjects (which should be JGLFWobjects, in my opinion) are also missing some useful functionality:
•     There does not seem to be any way of getting the values of various fields in the video modes (talking about the JGLFW variant). Also, there is no refresh rate anywhere in JGLFW.
•     Personal opinion: as GLFW is separated from JGLFW, all of the Java functionality should be contained in the GLFWobjects and not in the static methods. In other words, to poll state from a GLFWmonitor or a GLFWwindow, you would use getters in the instances themselves. Currently, in the case of GLFWmonitor, you can only get the width and height through the instance itself and everything else with the glfw* methods, which in my opinion is bad design.

Other than those, I have not encountered any issues. I do want to ask, what is the benefit of using JGLFW over directly using GLFW? Other than you don't need to deal with native functions and pointers, of course.

[spasi]

Hey EnergyRay,

JGLFW is a proof-of-concept implementation of GLFW and basically a huge unit-test for the bindings generator. It is not meant to replace the direct GLFW bindings. I haven't made any serious effort to make it more Java/OO friendly, it's actually an almost line-by-line port of the GLFW internal C implementation. Which is what I was trying to prove; that it's possible to write such low-level code in pure Java, simply by using the underlying OS-specific APIs.

JGLFW is both incomplete (no OSX implementation) and hasn't been updated with the latest GLFW features. At the time it was written I was considering putting more effort and having it around as an alternative back-end, but eventually decided it wasn't worth it. The point still stands though that if an LWJGL user requires direct OS-specific access and custom features, they should be able to implement their own back-end.

Other than that, the only benefit of JGLFW is custom context management. In the official GLFW build windows and contexts are coupled; you cannot configure the OpenGL context in a way that's not exposed by the GLFW API. This isn't too bad and good enough for most use-cases, but misses some important functionality last time I checked, especially vendor and OS specific extensions. I've managed to create custom GLFW builds that workaround this problem (context provided by LWJGL, window management by GLFW), but it's a bit of a pain to support properly. I'd rather make an effort to get whatever's missing into the official GLFW.

For now, my recommendation is to stick with the GLFW bindings and ignore JGLFW.

[EnergyRay]

Hey, Spasi!

That explains some of the weirdness in the design. I should probably start reading the source code a bit more though. Still, maybe add some clarification to the wiki?
In any case, I'm going to then write an OOP-wrapper around GLFW myself.

Well, thanks for clearing that up.

Ninja edit: This topic can be moved.