jogamp › jogl

GLcanvas vs NEWT on Hi DPI Screens

Classic

List

Threaded

16 messages Options

mahesh

GLcanvas vs NEWT on Hi DPI Screens

I am using JOGL 2.4 for my java application. I runs fine on default 80/90dpi screen, but on hi dpi screen I made following observations.
Currenly App runs on Java8 with dpiaware flag set to false, but on high dpi screens, swing UI as well as Graphics on opengl appear blurry, which is obvious due to scaling.

If I switch to java 9, Swing UI renders fine on high dpi screens but NEWT canvas window shrinks to quarter of screen (since pixelScaleFractor =2 in this case). Even scaling viewport has no effect on it. I think there is some problem with NEWT Canvas implementation (atleast on windows) which does't let canvas fill up whole space.

I tested by replacing NewtWindow with GLCanvas on Java9, it fills entire space, just I need to scale the GL viewport dimensions by pixel ScaleFactor.

Now there seem to be 2 solutions
1. Replace NEWT with GLcanvas, whcih will need rewriting mouse , key events listeners, adjusting framebuffers etc, but I will lose advantages of NEWT like mutitouch and some performace gains.
2. Wait for NEWT implemenation to be fixed (for windows in particular)

Is there some other solution or workaround?
Is there any plan of providing a fix for NEWT?

gouessej

Re: GLcanvas vs NEWT on Hi DPI Screens

Administrator

Hello

Please fill a bug report. Have you tried to modify the pixel scale to work around this problem?

Julien Gouesse | Personal blog | Website

mahesh

Re: GLcanvas vs NEWT on Hi DPI Screens

This post was updated on .

Have you tried to modify the pixel scale to work around this problem?

gouessej wrote

Have you tried to modify the pixel scale to work around this problem?

Yes I used that but it works in GLCanvas but not in NEWTCanvas (my machine is windows surface pro 6).
I looked into several discussions in the forum, but could't conclude if NEWTcanvas deals with highdpi on windows or not.

The problem is, not getting pixelScale but NEWTCanvas is not resizing to fill the whole window. For pixelScale=2 (hihdpi monitor), it is filled in just 1/4th part. For pixelScale=1 (normal monitor) it fills completely. Is it a known bug?

gouessej

Re: GLcanvas vs NEWT on Hi DPI Screens

Administrator

Please comment the following bug:
https://jogamp.org/bugzilla/show_bug.cgi?id=1374

Julien Gouesse | Personal blog | Website

mahesh

Re: GLcanvas vs NEWT on Hi DPI Screens

This post was updated on .

Would you please create bugzilla account for my Mail:
ma*******010@gamil.com

gouessej

Re: GLcanvas vs NEWT on Hi DPI Screens

Administrator

Please send me an email so that I can give you your password in return. Don't post your email address here, some spam bots will see it :s

Julien Gouesse | Personal blog | Website

mahesh

Re: GLcanvas vs NEWT on Hi DPI Screens

In reply to this post by mahesh

I have two workarounds which work fine with JDK9 and windows 10.
1. Set layout as null, and manually scale dimesions of canvas by pixelScaleFactor.
2. Override getPreferredSize() ,getWidth() and getHeight() of NewtAwtCanvas and return scaled dimensions.

Associated test snippet can be found here.
https://gist.github.com/maheshkurmi/e984430d33236b6bfb7c3de0f8a1a0e5

gouessej

Re: GLcanvas vs NEWT on Hi DPI Screens

Administrator

Don't forget to mention it in a bug report.

Julien Gouesse | Personal blog | Website

Martin

Re: GLcanvas vs NEWT on Hi DPI Screens

Hi,

Mahesh fix is good but it is not dynamic. It forces a multiplying factor of 2, whatever the actual pixel scale. This won't work properly on screens with 1.5 pixel scales. This will also prevent programs ran on Java <= 8 to keep their pixel scale = 1 (The JVM only detects HiDPI as of Java 9).

I made a tiny improvement visible here : https://gist.github.com/jzy3d/bc392d97fe8bd956470a2f8f002f4c87

It basically get pixel ratio from the AWT Component Graphics instance :

@Override
public int getWidth() {
double scale = getPixelScaleX();

return (int)(super.getWidth() * scale);
}

@Override
public int getHeight() {
double scale = getPixelScaleY();

return (int)(super.getHeight() * scale);
}

protected double getPixelScaleX() {
Graphics2D g2d = (Graphics2D)getGraphics();
AffineTransform globalTransform = g2d.getTransform();
return globalTransform.getScaleX();
}

protected double getPixelScaleY() {
Graphics2D g2d = (Graphics2D)getGraphics();
AffineTransform globalTransform = g2d.getTransform();
return globalTransform.getScaleY();
}

Sven Gothel

Re: GLcanvas vs NEWT on Hi DPI Screens

Administrator

Great job Mahesh & Martin, Julien ..

I will consider this for 2.4.0 and thx for putting it in bugzilla as well.

One question, would you expect this pixel scale also being used 'naturally' by a NEWT window (w/o AWT)?
In such case we would have seamless pixel scale in NEWT, AWT or not (Note: reparenting is possible).
That probably means to read out the windowing system's pixel scale,
potentially an environment variable or something.

When I added the pixel scale API .. well, it was mostly for NEWT and a client request :)

For NEWT, I was hoping ppl would use the monitor DPI info we provide to render the
objects in the desired _size_. But who am I to judge and choose :)

So status is pixel scale works
- using GLCanvas + GLJPanel
- using MacOS anyways (in NEWT too)
- missing for NEWT alone and with NewtCanvasAWT

?

- Our Bugzilla issue 1374 https://jogamp.org/bugzilla/show_bug.cgi?id=1374
- Martin's issue tracker https://github.com/jzy3d/jogl/issues/8
- This forum post https://forum.jogamp.org/GLcanvas-vs-NEWT-on-Hi-DPI-Screens-tp4041191p4042115.html
- Harvey's kicking https://forum.jogamp.org/Release-2-4-0-Progress-tp4042061p4042114.html

hharrison

Re: GLcanvas vs NEWT on Hi DPI Screens

WRT the HiDPI issues, I'm totally fine implementing appropriate code in jaamsim if that is the suggested solution (suggestions welcome), or making the NextCanvasAWT handle it all internally if it can. Will wait to see what comes out of this conversation before changing anything on my side.

On the Jaamsim side we just have a NewtCanvasAWT filling a lone JFrame, so as I understand it we could hook into the move listener on the JFrame and check the pixel scale as the window is moved across different screens as adjust the pixelscale as needed...examples welcome!

Harvey

Sven Gothel

Re: GLcanvas vs NEWT on Hi DPI Screens

Administrator

In reply to this post by Sven Gothel

I added a comment in Bug 1374, detailing the procedure to read the custom pixel-scale.
See https://jogamp.org/bugzilla/show_bug.cgi?id=1374#c7

'pixel scale', an arbitrary scaling factor,
customized by the user, to please the eyes etc.
This in contrast to actual DPI naturally scaled rendering. 'true to scale'.

+++

Generic way to determine the OS's windowing system's so called 'pixel scale':

Windows:
1a) GetDpiForMonitor(ddmon, MDT_EFFECTIVE_DPI, int *dpi_x, int *dpi_y)
- NOTE: MDT_EFFECTIVE_DPI returns the custom user DPI setting
according to user pixel scale setting (See above).
This is not the true dpi, which NEWT already calculates
per monitor by its size and resolution!
(or attribute MDT_RAW_DPI here)

or, if 1a is n/a

1b) { dpi_x, dpi_y } = GetDeviceCaps(hdc, {LOGPIXELSX, LOGPIXELSX})
- NOTE: Same for all monitors

2) pixel_scale_x = (float)dpi_x / (float)96
pixel_scale_y = (float)dpi_x / (float)96

Unix:
0) See https://wiki.archlinux.org/title/HiDPI

1) KDE Plasme: How to read the setup value?
- System Settings > Display and Monitor > Display Configuration > Global Scale
- range 100 - x00% in 25% steps, i.e. float

2) Qt5: QT_SCREEN_SCALE_FACTORS, QT_SCALE_FACTOR, ...
3) ...
9) GDK3+ GTK3/4: int GDK_SCALE, an environment variable
- NOTE: just an int type, not pleasing - from GDK3 world

Note: JDK-17 seems to use GDK_SCALE only ..
Note: We might end up using an AWT Compatibility mode
- and - a proper pixel scale mode (when and if available)
Note: Needs more investigation.

Debugging w/ AWT:
X) float J2D_UISCALE, an environment variable
- Windows: value is kept as float
- Unix: valye is cut-off to int (duh!)

.. to be continued ..

.. additional note: On X11/Unix, well, we have a lot of options, i.e. even xrandr
using hw-accel scaling w/o need to interfere from our side as all gets scaled.

Sven Gothel

Re: GLcanvas vs NEWT on Hi DPI Screens

Administrator

Historical note:
- Bug 1120 added general pixel-scale https://jogamp.org/bugzilla/show_bug.cgi?id=1120
- com.jogamp.nativewindow.ScalableSurface covers this throughout our API
across our windowing systems like NEWT, GLCanvas/AWT, ...

Sven Gothel

Re: GLcanvas vs NEWT on Hi DPI Screens

Administrator

https://jogamp.org/bugzilla/show_bug.cgi?id=1374#c10

NEWT:

On the MacOS and iOS,
window units are used for the native UI component's position and size.
Here the surface size in pixel units = window-units-size * pixelScale.
This has been implemented already.

On Windows-GDI and X11,
pixel units are used for the native UI component's position and size.
Here we need to convert NEWT's window position and size
to and from the pixel-size, i.e. window units = pixel-units / pixelScale.

Hence all NEWT window-unit position and size values must
be appropriately converted from/to window-units on Windows and X11.

WIP ..

.. bottom line, I am working integrating pixel-scale semantics into NEWT
for all non MacOS/iOS platforms.

Sven Gothel

Re: GLcanvas vs NEWT on Hi DPI Screens

Administrator

In reply to this post by Sven Gothel

NEWT's Soft-PixelScale done, used for X11 and Windows.
See
<https://jogamp.org/cgit/jogl.git/commit/?id=97b79ad351e48e7d3c6f9c95bacdf4f9d5d158ef>

TODO: Test and fix utilization with AWT, i.e. NewtCanvasAWT

Sven Gothel

Re: GLcanvas vs NEWT on Hi DPI Screens

Administrator

Soft PixelScale on X11/Windows
=======================
.. we sort up end up with the requirement of mapping window-units <-> pixel-units
taking the monitor viewport layout into account.

X11/Windows: A simple scaling of the window-units position is not suitable due to multiple monitors,
i.e. a window-units gap will be created and fullscreen/spanning coordinates will be wrong.

TODO: Implement seamless conversion of units incl. monitor viewport mapping
- X11, Windows: Recalculate monitor window-units viewport (native is pixels)
- MacOS Recalculate monitor pixel-units viewport (native is 'points', aka window-units)

Impact will be to have the ability to use either pixel- or window-units
for positioning and size and hence be fully platform independent.

Not sure how and when to complete this task and where to cut the line ..
This work asks to be resolved to have a nice solution though.

(Or it is 'Looking for a problem'? Discussion welcome)