JME3.3 resizable does not work?

So I have noticed that with resizable set to true in app settings, that it does not behave as expected.
For example, a newly created window:

Then resized:

So I wrote a quick test:

package io.tlf.outside.client.appstate;

import com.jayfella.jme3.graphics.Graphics;
import com.jme3.app.Application;
import com.jme3.app.SimpleApplication;
import com.jme3.app.state.BaseAppState;
import com.jme3.post.SceneProcessor;
import com.jme3.profile.AppProfiler;
import com.jme3.renderer.RenderManager;
import com.jme3.renderer.ViewPort;
import com.jme3.renderer.queue.RenderQueue;
import com.jme3.texture.FrameBuffer;
import javafx.scene.Scene;

public class GraphicsAppState extends BaseAppState {

    private SimpleApplication app;

    @Override
    protected void initialize(Application app) {
        Graphics.initialize(app); //Init our graphics handler so that we can manage the app settings
        this.app = (SimpleApplication) app;
        this.app.getViewPort().addProcessor(new ResizeProcessor());

        System.out.println("Graphics init");
    }

    @Override
    protected void cleanup(Application app) {

    }

    public void update(float tpf) {
        System.out.println(Graphics.getInstance().getContextSettings().getResolutionWidth() + "x" + Graphics.getInstance().getContextSettings().getResolutionHeight());
    }

    @Override
    protected void onEnable() {

    }

    @Override
    protected void onDisable() {

    }

    private class ResizeProcessor implements SceneProcessor {
        private boolean resizeLoaded = false;

        @Override
        public void initialize(RenderManager rm, ViewPort vp) {
            System.out.println("Resize init");
            resizeLoaded = true;
        }

        @Override
        public void reshape(ViewPort vp, int w, int h) {
            System.out.println("Resized");
        }

        @Override
        public boolean isInitialized() {
            return resizeLoaded;
        }

        @Override
        public void preFrame(float tpf) {

        }

        @Override
        public void postQueue(RenderQueue rq) {

        }

        @Override
        public void postFrame(FrameBuffer out) {

        }

        @Override
        public void cleanup() {

        }

        @Override
        public void setProfiler(AppProfiler profiler) {

        }
    }

}

Resized is never printed to console, thus reshape is not triggered on the viewport.

Digging deeper,
Line 260 in LwjglWindow:

        // Add a resize callback which delegates to the listener
        glfwSetWindowSizeCallback(window, windowSizeCallback = new GLFWWindowSizeCallback() {
            @Override
            public void invoke(final long window, final int width, final int height) {
                settings.setResolution(width, height);
                listener.reshape(width, height);
            }
        });

I would expect the resolution to be changed in the settings at least, but from the output of the test, it is not.

Is this broken, or am I missing something here?

EDIT:
I should clarify, I am on windows 10, on the latest copy of master.

1 Like

Looks to be related to : TestResizableApp crashes with LWJGL3 on Windows · Issue #1191 · jMonkeyEngine/jmonkeyengine · GitHub

1 Like

Yeah, it sure is. We are using the wrong callback with LWJGL 3. The fix seems kinda easy, just change the callback. I have it already in my branch. But there is the HDPI thing that should be addressed maybe at the same time. At least understood that when it is an actual resolution (window size, point per pixel etc.) change and when it is just a canvas resize.

But this might be deeper in JME also. When to use the window size and when the viewport size. Given that the viewport size is the scaled size when points & pixels do not match. And keeping LWJGL 2 compatibility.

Sorry about the terminology, might not be 100% accurate, I’m a bit n00b on this.

3 Likes

@tonihele would you be willing to open a quick PR to change the call back to the correct one for beta2 of 3.3? Then the HDPI issues can be addressed at a later date?

1 Like

Yeah, it’s best to fix one problem at a time for stuff like this.

Sure, just a moment. Ill just modify it so that it doesn’t even try to fix the HDPI but works as JME used to, sort of

Sorry for the delay. I made some changes to perfectly try to emulate LWJGL 2 behavior.
https://github.com/jMonkeyEngine/jmonkeyengine/pull/1308

2 Likes