SWT GLCanvas renders incorrectly at 175% scaling and above on Windows

Hi,

I am using the SWT GLCanvas (com.jogamp.opengl.swt.GLCanvas) in JOGL 2.5.0.  Rendering works perfectly until I increase the Windows 10 scaling to 175% and beyond.  Then the canvas only renders to the bottom left quadrant, as below:



(In the above image, the square should encompass the entire dialog)

I can work around this to some degree by setting the viewport width and height to 2 times that of the reported canvas size.  However, I also use the TextRenderer class and that causes the text to appear blurry (because it is bitmap zooming x 2).

Is there a workaround for this?

Thanks,

James

Hi,

I've been playing with the NEWT GLCanvas which seems to allow me to avoid the scaling issue.  Basically, if I do the following:

1.  Set the surface scale value to 1.0f using:

    glCanvas.getNEWTChild().setSurfaceScale()

2.  Set the viewport size in the reshape callback with:

    gl.glViewport(0, 0, drawable.getSurfaceWidth(), drawable.getSurfaceHeight());

    (where "drawable" is the first argument in the callback).

Then rendering appears correct at 175% scaling - it correctly fills the canvas and text is not scaled horribly.

Is this the recommended solution to handling 175%+ scaling, or is there a way I can get it to work using the com.jogamp.opengl.swt.GLCanvas instead?

Any help would be great, thanks :-)

James

I'm probably talking to myself here, but a further update:

The NewtCanvasSWT works a dream on Windows, but unfortunately on Linux it is a mess.  Attempting to resize the canvas causes the rendered area to disappear off the canvas.  It appears that the X/Y location of the GLCanvas is set incorrectly somehow (it is 0,0 prior to resize and then seems to change to an absolute XY).

So unfortunately, I'm back to Eclipse/JOGL standard SWT canvas and broken handling of scaling....

badjames wrote

I'm probably talking to myself here, but a further update:

You aren't.

Maybe there is a bug report for this problem with a workaround, it reminds me something.

Sorry, it's not the best time to provide some help for me.

No problem, thanks for responding :-)

I think for the moment I'll see if I can abstract things so Windows can take advantage of the NEWT canvas, but Linux will use the older SWT canvas.  Most of my users will likely be on Windows anyway, so poor scaling on Linux may not be an issue.

If you do think of anything, let me know and I'll revise things.

Merry Xmas :-)

James

Hi -- in GAMA (https://gama-platform.org) we use NEWT Canvases for rendering in Windows, Linux and macOS. However, one thing we noticed is that the latest version of JOGL is broken on Linux, so we have to use a version which was specifically compiled by the designer of JZY3D. I think it more or less corresponds to a 2.4.0 version with some additional tweaks so it can run on Mx Apple processors, but Martin, the designer of JZY3D, can confirm that. You can find the jars on the Github repository of GAMA. Hope this helps !

Hi Alexis, thanks for that.

In the end, I was able to get the latest JOGL SWT canvas working well on all platforms without needing NEWT.  The only real issue was having to translate the scaled SWT event locations to the unscaled locations on the JOGL canvas.

If you have suggestions for a fix, please advise.
Is the issue still existing? (I assume since we had no changes since 2.5.0 in this realm)

In short, is there work to do in the (SWT) scaling domain to work out of the box
useful for 2.6.0?

Hi Sven,

I think the JOGL SWT canvas is fine regarding scaling.  The only thing I've needed to do is handle conversion of the scaled SWT events to the unscaled SWT canvas size.

James

For GLCanvas, the only fix I found to fix the Windows Display Scale problem (when at 125%, 150%, 175% etc...) was to use Toolkit to get the scale and apply the factor to width & height like this:

        Toolkit toolkit = Toolkit.getDefaultToolkit();
        int screenDPI = toolkit.getScreenResolution();
        // Standard DPI for 100% scaling is 96 DPI
        double standardDPI = 96.0;
        // Calculate the scaling
        scale = screenDPI / standardDPI;

Then set the viewport like this:

        int fbWidth = (int)(scale * width);
        int fbHeight = (int)(scale * height);
        gl.glViewport(0,0,fbWidth,fbHeight);

Hope this helps somebody


       

Thank you Alex,

so it all boils down to detecting the 'scaling change' after launching the application,
here in this use-case SWT (but valid for all others too).

Changing the windows scaling at runtime is to my knowledge only possible on Windows(?).

Guess I can add a more convenient automated way to read the change
to trigger a reshape event.

https://jogamp.org/cgit/jogl.git/commit/?id=0d8503412ab8729e2d33f181bebe9a779f253cab

Test: SWT High-DPI Soft-PixelScale on Windows
   
On Windows ans SWT >= 4.36, set system property `-Dswt.autoScale.updateOnRuntime=true`
to enable using the Windows scale factor.

+++

Besides, I have also resolved the following related issues

Bug 1524 - NEWT High-DPI Soft-PixelScale on X11/Windows: Honor OS Scale-Factor at Creation + Change
https://jogamp.org/bugzilla//show_bug.cgi?id=1524

Bug 1525 - SWT High-DPI X11/GTK: Wrong Scaling since SWT 4.36 (update)
https://jogamp.org/bugzilla//show_bug.cgi?id=1525

My apologies Sven, I was using an older version of jogamp in my project, where I had to correct the viewport width and height. But I just upgraded jogamp to version 2.5 and noticed that you already fixed that. The correction is no longer necessary. Works like a chram at any Windows Scale  %
Thank you for all the work you (and your team) have put into this project! Good Day!

Great.

Please also test w/ latest v2.6.0 RC (6th build)
https://forum.jogamp.org/Release-2-6-0-tp4042889p4043867.html

I changed (fixed I hope) some SWT and NEWT (soft) scaling (X11/Windows).