Lwjgl3: glfw on Mac

[EmpsThomy]

It seems to be unable for glfw to gain focus on a Mac. I'm running the application with -XstartOnFirstThread but all user input is just ignored. It looks like the window cannot gain any focus, because user input is sent to the application opened before my lwjgl application. So all user input is sent to the Terminal with which I've opened my application.

I've tried googling the issue, but couldn't find similar propblems, so I suppose this is a bug? I've also already tried to give the window focus manually and to set GLFW_FLOATING to true, but without any luck.

I am using lwjgl-3.1.1 on macOS Sierra Version 10.12.4 with a GT650M.

[Spasi]

This symptom is usually caused by another Cocoa event loop running in the same process. This can happen if you try to interop with AWT/Swing or JavaFX for example.

Please note that even if you don't create a Frame/JFrame and simply try to load a texture in a BufferedImage, it is enough to trigger initialization of AWT. That's why LWJGL offers stb_image as a replacement for ImageIO.

[EmpsThomy]

Thanks for the quick reply. That indeed makes sense, I am using BufferedImage as internal representation for resizing / editing image data.

Would there be other solutions where I could use ImageIO? I've recently updated from lwjgl-2.9.0 to lwjgl-3.1.1and wouldn't mind rewriting input again, but internal data representation changes would be a lot more work.

[kappaOne]

If you must use some parts of AWT (such as BufferedImage or ImageIO) on OSX with GLFW, then a quick hack to make it work is to use the "-Djava.awt.headless=true" vm argument.

A better long terms solution as mentioned above is to not use AWT at all and uses solutions such as STB for image loading.

[Spasi]

That indeed makes sense, I am using BufferedImage as internal representation for resizing / editing image data.

Would there be other solutions where I could use ImageIO? I've recently updated from lwjgl-2.9.0 to lwjgl-3.1.1and wouldn't mind rewriting input again, but internal data representation changes would be a lot more work.

Using stb_image, you get the image data in a ByteBuffer or FloatBuffer. You can use that directly instead of a BufferedImage. You can upload the image data as a texture, resize it with stb_image_resize (STBImageResize in LWJGL), or write it out to disk with stb_image_write (STBImageWrite in LWJGL).

[EmpsThomy]

Thanks to both of you, kappaOne and Spasi! I'll try to run the application with -Djava.awt.headless=true and reconstruct image handling in future expansions with the stb_ functions. Their ByteBuffer or FloatBuffer can directly be used with the lwjgl functions to store textures on the graphics card. That's actually really handy.

[EmpsThomy]

Quick follow-up. Setting -Djava.awt.headless=true works like a charm, really good tip, thanks! I've now run into an issue with DPI scaling though, also on the Mac.

I know that display of the mac I am testing the application with is scaling down the application to run in 1440x900. This works correctly when querying the cursor's position with glfwSetCursorPosCallback, I get cursor position values between 0x0 and 1400x900. However, the glfwSetFramebufferSizeCallback returns the actual size of the window, without taking any scalings into consideration. This in fact screws up the entire internal mouse pointer handling, because positions are off.

Is that correct behavior, or is there a way of disabling/enabling DPI scaling for position values of
both methods glfwSetCursorPosCallback and glfwSetFramebufferSizeCallback?

[sriharshachilakapati]

I don't think that matters here because to get mouse in world you'd want to
unproject it anyways with the combined matrix of the camera.

On Wed, 10 May 2017, 8:52 p.m. EmpsThomy, [e-mail] wrote:

Quick follow-up. Setting -Djava.awt.headless=true works like a charm,
really good tip, thanks! I've now run into an issue with DPI scaling
though, also on the Mac.

I know that display of the mac I am testing the application with is
scaling down the application to run in 1440x900. This works correctly when
querying the cursor's position with glfwSetCursorPosCallback, I get
cursor position values between 0x0 and 1400x900. However, the
glfwSetFramebufferSizeCallback returns the actual size of the window,
without taking any scalings into consideration. This in fact screws up the
entire internal mouse pointer handling, because positions are off.

Is that correct behavior, or is there a way of disabling/enabling DPI
scaling for position values of
both methods glfwSetCursorPosCallback and glfwSetFramebufferSizeCallback?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/LWJGL/lwjgl3/issues/306#issuecomment-300517427, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEYWNBBxh7MLOjjnLM6i0z3NlXcSymtRks5r4dZBgaJpZM4NWWm1
.

[EmpsThomy]

I was wrongly using glfwSetFramebufferSizeCallback to listen on window resize events. However, it works fine and as expected if I use the glfwSetWindowSizeCallback. I can find the DPI scaling factors by dividing the window sizes by the frame buffer sizes and can fix the issue. Thanks. :)

[Czarek-Mojang]

@kappaOne Is it safe to set headless mode in Main class with such code? Or is it necessary to pass it via VM argument?

static {
        System.setProperty("java.awt.headless", "true");
    }