LWJGL3 Window Utilities

LWJGL3’s “window manipulation interface” is a bit more convoluted compared to LWJGL2. I’ve always thought it would be nice if JME had some utility methods to make using 3 a bit easier.

But I’m on the fence about whether this should even be a JME responsibility.

To illustrate what I mean by “convoluted”, relatively speaking:


Display.setLocation(windowX, windowY);

Simple interface:

public static void setLocation(int new_x, int new_y);

‘context’ is a JmeContext. I know this could be written more concisely, but it would still be a nuisance.

LwjglWindow lwjglContext = (LwjglWindow) context;
long winHandle = lwjglContext.getWindowHandle();
GLFW.glfwSetWindowPos(winHandle, windowX, windowY);


public static void glfwSetWindowPos(long window, int xpos, int ypos);

This is one of the less annoying differences. Getting window position or size is worse. You need to pass two IntBuffers to capture the window width/height values, for example:

public static void glfwGetWindowSize(long window, IntBuffer width, IntBuffer height);

(And if you’re calling this frequently, now you’re either creating extra garbage with those buffers, or you have to keep them around to re-use.)

None of this is a problem; it’s just a slight annoyance and inconvenience–another reason I’m not sure it’s worth putting in JME.

Another idea, apart from a simple LWJGL3 utility class, is to have JME provide a standard interface which LWJGL2, LWJGL3, and JOGL could all implement. I imagine it would look similar to parts of LWJGL2’s Display class (static methods with minimal parameters).

It was suggested that I ask here to solicit some additional opinions on whether this is worth adding.
…Any thoughts?

Well, I mean, in JME it 100% would not be static methods. That much I can say for sure.

I think the reason they aren’t static in lwjgl3 is because there can be more than one window? (not familiar with 3 but that’s what the API implies).

I think LWJGL3 just exposes the GLFW-binding


I don’t think LWJGL3 even have their own window/context-creation anymore, it’s all GLFW I believe.

Multi-window might have been a factor, but at least some of these methods work fine as statics even with multiple windows due to that window handle parameter. I haven’t looked at the entire API they’re exposing yet, just things I’ve wanted to use before.

Some of these could definitely be static. Are you opposed to statics for design reasons for because there’s some technical limitation that prevents it? For 2, these were all static.

When I get a chance I’ll post a list of ‘candidate api’ that would be the goal, if this enhancement is judged useful, I realize it’s a little fuzzy right now.

@jmaasing Yes these are all GLFW calls.

Yes THEIR methods are static because they pass a window handle to support multiple windows. That’s because they are essentially a C API rendered in Java.

JME is not a C API. It’s an OOP API. So should not have static methods for this… else JME would be forever forced into a single window design.

lwjgl2 has static methods because I guess they only ever support one display at a time.