JOGL specification version 2.4
JOGL implementation version 2.4.0-rc-20221130
JOGL implementation vendor JogAmp Community
I'm working with NASA WorldWind's "InstallImagery" example. On a Windows 11 platform with Java 11, when I set the text scaling to something other that 125%, the GLCanvas doesn't fill the entire application pane, e.g.,
It looks like the scaling updates are not working properly. I turned on jogl.debug.GLCanvas=true, and I don't see the scaling change in the log output:
The initial size of the canvas is set to 1000x800, but that doesn't seem to change even though the frame containing resizes when the text size changes. The display is the same if the text scaling is set to 125% before starting the application.
It looks like GLCanvas.updatePixelScale is being called before JAWTWindow.updatePixelScale, and the jawtWindow.hasPixelScaleChanged() return is false when called in GLCanvas.
I did some work regarding the fake-97DPI scaling for Windows and even Linux/X11 within NEWT itself.
I have a thread here somewhere .. and its marked NEWT Soft-PixelScale in the git commits.
While it works on using NEWT windows, it also needs some update on the NEWT multi-monitor management.
I have not tested this with pure AWT, as I assumed that this code-path is already working.
It almost seems like the scaling is going in the wrong direction. Or the OpenGL code is drawing in physical size pixels, when it should be drawing in logical size pixels. Or the coordinates should be scaled before passing them to the OpenGL code.
Apparently this problem exists with LWJGL as well. Here are two posts. I haven't been able to get the solution proposed to work yet, nor do I especially like it.
I've been working on Windows 10 and 11, using OpenJDK jdk-22.214.171.124-hotspot. I'm working with a recently cloned copy of the gluegen/jogl repos. Native libraries were built with gcc 12.2.0 under Msys2/MinGW.
When I run with OpenJDK jdk-126.96.36.199-hotspot
Exception in thread "main" com.jogamp.opengl.GLException: Unable to determine GraphicsConfiguration: WindowsWGLGraphicsConfiguration[DefaultGraphicsScreen[WindowsGraphicsDevice[type .windows, connection decon, unitID 0, handle 0x0, owner false, NullToolkitLock[obj 0x4aafad9d]], idx 0], pfdID 8, ARB-Choosen true,
requested GLCaps[rgba 8/8/8/0, opaque, accum-rgba 0/0/0/0, dp/st/ms 16/0/0, dbl, mono , hw, GLProfile[GL4bc/GL4bc.hw], on-scr[.]],
chosen GLCaps[wgl vid 8 arb: rgba 10/10/10/2, opaque, accum-rgba 0/0/0/0, dp/st/ms 24/8/0, dbl, mono , hw, GLProfile[GL4bc/GL4bc.hw], on-scr[.]]]
Yeah, when fixing this I will use our way of determining the actual scale to 'size-up' out drawable surface.
A PIA so to speak but doable having all behavioral data in :)
So same bug with Windows and MacOS here on fractional scale.
Great, but warning .. this may become a deep dive :)
The last related git commits include NEWT Soft-PixelScale in the subject.
Bugs related and new commented are in Bug 1374.
In NEWT, we have different means to pull the pixel-scale from the system
- Windows: GDI, see GDIUtil.GetMonitorPixelScale()
- OSX: OSXUtil.getScreenPixelScaleByDisplayID()
- Note: NEWT also considers the specific native view/window configuration.
- Linux: Environment variable, see SurfaceScaleUtil.getPixelScaleEnv()
Currently, in our AWT GLCanvas, we use:
and this might be an issue or something, despite the fact that we use floats.
This method sort of does the very same path as all other are using for a workaround.
However, it uses one method for Java < 9
and one method for Java >= 9.
The latter (Java >= 9) simply uses the generic GraphicsConfiguration's AffineTransform's x/y scale factor
which is a double, so float compatible if you want.
This JAWTUtil method is currently used in
- used in GLCanvas
When I would start this journey, I would first hack-in code to show me
the actual pixel-scale (using the mentioned NEWT methods)
and the JAWTUtil scales used.
Assuming full integer scales work, but we got a 'float bug',
probably AWT using just integer.
In the latter case, we would need to use the ceiling of rounded float, done :)
HiDPI: Revise AWT GLCanvas/GLJPanel ScalableSurface: No setSurfaceScale(), have AWT toolkit define pixelScale only (simplification)HEADmaster
This aligns with Glenn's initial AWT patch commit e5e7514d649cd7dd28bbb8e04b72338dc09c2c83, i.e. removing redundancies...
Tested on Linux, Windows and MacOS w/ GLCanvas, GLJPanel and GLWindow using pixelScale values:
- Linux: 1, 2
- Windows: 1, 1.25, 2
- MacOS: 1, 2