canvas not filling frame

When using the latest builds for JOGL on Windows 64 (jogl-b1483-1483), I can get a Java 13/JOGL program to compile and run (with some warnings about illegal reflective access). However, the canvas does not fill the frame - it fills the bottom left area of the frame. For the same program, it used to fill the frame under Java 8/JOGL2.3.2.
Any suggestions?
I can post the program to draw a single '2D' triangle if that helps.

On 10/8/19 3:43 PM, Steve Maddock [via jogamp] wrote:
> When using the latest builds for JOGL on Windows 64 (jogl-b1483-1483), I can
> get a Java 13/JOGL program to compile and run (with some warnings about
> illegal reflective access). However, the canvas does not fill the frame - it
> fills the bottom left area of the frame. For the same program, it used to fill
> the frame under Java 8/JOGL2.3.2.
> Any suggestions?
> I can post the program to draw a single '2D' triangle if that helps.

it would help if you could just test with one of the many
unit tests, like com.jogamp.opengl.test.junit.jogl.demos.es2.newt.TestGearsES2NEWT

However, either you wait for the pre-release build
or you build the java11 branch, older versions won't help.

~Sven

I have this same problem. I think it's related to DPI scaling in windows. With scaling set to 200%, my GLCanvas is a quarter the size it should be, and positioned in the bottom-left corner. I have not had time to try compiling the Java11 branch to see if that fixed this problem.

Even if this problem is fixed in JOGL, I wonder if we will still have problems with mouse coordinates in Java 11. The reported values get affected by DPI scaling as well, and I see no way to disable that for a specific JPanel/GLCanvas without disabling DPI-scaling for the entire program.

-Farrell

By the way, could this problem be related to HiDPI too?
https://jogamp.org/bugzilla/show_bug.cgi?id=1395

I found a workaround for this problem.

In your GLCanvas's resize() method, do this before the rest of your code:

GL2 gl = drawable.getGL().getGL2(); // change this as needed
double dpiScalingFactor = ((Graphics2D) getGraphics()).getTransform().getScaleX();
width = (int) (width * dpiScalingFactor);
height = (int) (height * dpiScalingFactor);
gl.glViewport(0, 0, width, height);
// then put the rest of your code here...

This fixes the problem for me. Tested with AdoptOpenJDK's Java 13 in Windows 10. And it does not seem to break backwards compatibility with Java 8 either, since dpiScalingFactor would always be 1.0 in that case.

Some notes:

If you use MouseListeners, you also need to scale the mouse location. So make dpiScalingFactor a global, and then do "int mouseX = (int) (mouseEvent.getX() * dpiScalingFactor);" etc. in your event handler. I found no way to get the mouse location in true pixels, so you lose some precision, but at least it works. If anyone knows a better way, please share.

I found that "((Graphics2D) getGraphics()).getTransform().getScaleY()" always returns 0.0, so I just assume square pixels. Do any currently used displays have non-square pixels?

I have not tested my workaround on Linux or macOS.

My workaround is based on this info I found:
https://stackoverflow.com/questions/43057457/jdk-9-high-dpi-disable-for-specific-panel

-Farrell

I had the same problem with the JDK 11 and World Wind Java on Windows 10.

I modified the GLCanvas.java

  private final boolean updatePixelScale() {
      if( jawtWindow.hasPixelScaleChanged() ) {
          jawtWindow.getMaximumSurfaceScale(maxPixelScale);
          jawtWindow.getMinimumSurfaceScale(minPixelScale);
          System.arraycopy(maxPixelScale, 0, hasPixelScale, 0, 2);
          return setSurfaceScaleImpl(jawtWindow);
      } else {
          return false;
      }
  }

This modification works well for me with all JOGL 2.4 applications.

On 10/10/19 11:00 AM, gouessej [via jogamp] wrote:
> By the way, could this problem be related to HiDPI too?
> https://jogamp.org/bugzilla/show_bug.cgi?id=1395

Please notice that Bug 1374 has been reopened
<https://jogamp.org/bugzilla//show_bug.cgi?id=1374#c3>.

In general all High-DPI issues shall be fixed for 2.4.0 release
<https://jogamp.org/wiki/index.php?title=SW_Tracking_Report_Feature_Objectives_Overview#High_DPI>.

+++

Thank you Julien, need to check Bug 1395 as well,
but seems to be a different issue.

~Sven

Please notice that Bug 1374 has been reopened
<https://jogamp.org/bugzilla//show_bug.cgi?id=1374#c3>.

In general all High-DPI issues shall be fixed for 2.4.0 release
<https://jogamp.org/wiki/index.php?title=SW_Tracking_Report_Feature_Objectives_Overview#High_DPI>.

~Sven