Posted by gbburkhardt on Apr 16, 2023; 7:22pm
URL: https://forum.jogamp.org/intent-of-reqPixelScale-in-GLCanvas-tp4042430p4042464.html

I think I figured out that 'setSurfaceScale' and the underlying 'reqPixelScale' are not intended to be used for Windows and X11, but rather is an OSX feature.  Is that correct?

FWIW, the changes in that patch are never executed by TestGearsES2NEWT, at least on Windows, because the demo uses GLWindow, not GLCanvas.

On a Windows computer with DPI scaling at 125% and "-pixelScale 1.0" and , the surface's 'reqPixelScale' is 1.0, and 'hasPixelScale' is 1.25.  The frame size is 640x480, but the imageWidth and imageHeight passed to GearsES2:reshapeImpl() is 800x600.  I think that means that drawing is done on a 800x600 canvas.

That's because in jogamp.newt.driver.windows.WindowDriver:

    private boolean updatePixelScaleByMonitor(final long crt_handle, final int[] move_diff, final boolean sendEvent, final boolean defer) {
        boolean res = false;
        if( 0 != crt_handle ) {
            final float newPixelScaleRaw[] = { 0, 0 };
            if( GDIUtil.GetMonitorPixelScale(crt_handle, newPixelScaleRaw) ) {
                res = applySoftPixelScale(move_diff, sendEvent, defer, newPixelScaleRaw);
            }
        }
        return res;
    }


So for Windows, at least, "-pixelScale" doesn't do anything in that demo program.

It doesn't seem right that the user should be able to affect the pixel scaling.  Was that intended to allow DPI scaling independence?

My concern is that my patch is incomplete, or will break some feature.  But if for X11 and Windows 'reqPixelScale' and 'setSurfaceScale' shouldn't have any effect, I'm happy.  I had discovered that NASA had used 'setSurfaceScale' to work around the DPI scaling problem my patch was intended to fix.

I'm happy that you characterized this as an "UI un-metric abyss".  It has been so confusing.  I admire all the code that's in JOGL that handles all the different platforms.