intent of reqPixelScale in GLCanvas

What's the intent of the value 'reqPixelScale' in GLCanvas?  I see that the setSurfaceScale method allows the end user to set those values.  After that's been done, should the glautodrawable.getSurfaceWidth() and glautodrawable.getSurfaceHeight() return the scaled values of the logical frame size, using the current DPI scaling?  I suspect that's correct, and the drawable surface should always fill the frame in which a GLCanvas is embedded.

If that's the case, my pull request JAWTWindow:reqPixelScale before the DPI scaling factor is determined needs more work.

Yes and its throughout the 'scaled surface' API.

Is it the case that the use of 'reqPixelScale' is still a work in progress?  Using "-pixelScale 1.0" for the demo TestGearsES2NEWT doesn't affect the surface width/height.  I notice it printing this line:

HiDPI PixelScale: 1.0x1.0 (req) -> 1.0x1.0 (val) -> 1.25x1.25 (has)

Is there some demo that shows the expected use of 'setSurfaceScale()'?  I haven't been able to find one.

I suspect that it's intended to change the size of the drawable, but haven't found any code that changes the scaling for drawing.

My guess was that if the use changes the pixel scale with 'setSurfaceScale', drawing commands would give coordinates in scaled pixels.  For example, if DPI scaling is set to 125%, and the logical frame size is 640 x 480, the size of the region in device pixels will be 800x600.  Normally, 'hasPixelScale' would be 1.25.  If the user calls 'setSurfaceScale(1.0, 1.0)', my guess is that the intent was that drawing would be done in a region or 640x480, and that GL drawing calls would scale the commands to device area of 800x600.

I'm still puzzled by what 'setSurfaceScale()' is supposed to do.  Thanks.

Yes, it shall set the used surface scale of the existing or not yet existing window.
For the latter, we have to track it.

On OSX, we do set the surface scale ourselves having a high-dpi monitor,
if you would not, you would get a low or high density surface (err .. guess low density as default).
So, depending on he desktop setting, the user may get what is expected.
But we have to programmatically set the surface scale here,
hence separated scale of window-coordinates (low 71 or 96 dpi old fashioned pixel surface)
and the actual surface-coordinates for the pixels.

The MacOS logic should act as follows:
IF reqSurfaceScale = -1 == auto, use the default (desktop) setting -> high-dpi if available for examples
IF reqSurfaceScale > 0 (i.e. user requested) then try to use it if supported.

Now, this logic shall also work for Windows or X11,
with the "only" difference that the underlying surface-dimension always equals to the actual monitor density (high-dpi),
since the GDI or X11 toolkit only knows pixels.
Hence the windows coordinates must be multiplied by this imaginary-scale to get the desired real size ;-)

So yes, on your Windows or X11 a 125% scale shall bloat up the surface-dimension (in pixels)
and hence bloat up the window pixel-size .. and, imagine you work on a like 96 dpi monitor, the window size as well.

THIS adjustment for Windows and X11 has only one goal,
i.e. to adjust old applications window size to new high density monitors (make 'em readable, bloat pixel volume up).
Of course, if your eyes are no more as good, you can also use it to scale up the stuff as well.

Edit: I.e. you can't increase the actual monitor DPI (duh), so a higher 'scale' or multiple of the 96dpi leads to bigger
surface sizes assuming 96 dpi is '1'. On a 2*96dpi monitor one would need to set the scale to 2 for 1:1 pixels,
now this starts to confuse me myself and I shall not look so deep in this UI un-metric abyss  ;-)

For modern applications, eg using NEWT, such concept is not required as we can read the monitor metrics
w/ DPI and hence scale the application proportional to the display w/ DPI etc.
No scaling to a 96dpi multiple is required nor really welcome IMHO.

Edit: Think about HTML/CSS layout, we just would want to scale the UI proportionally and may just use
the mighty em-size. This concept is currently also used in GraphUI (tada) and you can resize your window
where the elements are simply resized automatically in a proportion fashion (the goal).
Here we just would use scaled Group Container containing elements and Groups, with elements
of a normalized size '1' (em size) scaled by their container etc.

Pixel counting is no more.

+++

For AWT usage it is essential to know the scale factor to get the expected pixel volume so to speak :)
For this application, the reqPixelScale shall have no meaning indeed and shall always work
by assuming it is in auto (-1) setting.

EDIT: AFAIK, the reqPixelScale should be used here in case the AWT window is not yet realized?
Meaning the AWT destination will request the new scale?
But again, I would need to dive into this code once again to resolve it with Windows/X11 in mind
to cooperate well w/ AWT.
If lucky I might get a little funding for that .. but one day will fix it anyways (or you do this).
In the meantime .. enhancing the GraphUI CSS alike layout ... (reason why I was also thinking about this issue here as of late).

gbburkhardt wrote

Is it the case that the use of 'reqPixelScale' is still a work in progress?  Using "-pixelScale 1.0" for the demo TestGearsES2NEWT doesn't affect the surface width/height.  I notice it printing this line:

HiDPI PixelScale: 1.0x1.0 (req) -> 1.0x1.0 (val) -> 1.25x1.25 (has)

Is there some demo that shows the expected use of 'setSurfaceScale()'?  I haven't been able to find one.

- didn't your patch override reqSurfaceScale, so it got 'dumped'?

- AFAIK the manual portion of the demos/test-code used it and I manually validated it
  w/ different MacOS settings. So it worked at least on that platform back then.

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.

gbburkhardt wrote

I admire all the code that's in JOGL that handles all the different platforms.

I admire it too but each time we have to implement a new feature, we have to carefully evaluate the implications and potential side effects, it's not trivial. I'd like to improve the mouse management by taking into account "raw" unconstrained relative moves but it requires at least 5 distinct implementations :s I give it as an example to explain that maintaining JOGL is time consuming, I spent several weeks (months?) in working around some driver bugs, another one requires my attention.

Goal was and is to flatten platform differences, at least in the top public APIs. Here its the semantics of whether the surface-size will be scaled (MacOS) or if its fixed and hence the window coordinates have to be scaled (Windows, Linux).

Additionally, the general semantics are a bit odd and on Windows + Linux sort of reverse (like Matrix multiplication).
So this naturally adds to the confusion.

Other API abstractions we have are AFAIK not that difficult to my knowledge, or at least they are mostly straightforward.

Hmm, I saw no issue with the NEWT mouse pointer API when integrated it with GraphUI, we did that somewhat together back then AFAIK - consolidating touchpad + mouse to multi-pointer.

But of course, complexity is high when changing something in-between the public API and the platform-code, as side-effects are always possible and auto-testing certain UI feats are hard, especially interaction.
For the latter I used AWT-Robot and our own 'mouse control -> warp' .. still, its a big thing.

Hence hacking now on general simple UI layout and math is a breeze :)

But I will come back to this to fix it .. and I am glad that we have other testers like you here.

Sven Gothel wrote

Additionally, the general semantics are a bit odd and on Windows + Linux sort of reverse (like Matrix multiplication).
So this naturally adds to the confusion.

DirectXMath uses row-major order whereas OpenGL uses column-major order by default but some methods accept GL_TRUE for the "transpose" parameter. Is it what you meant?

Sven Gothel wrote

Other API abstractions we have are AFAIK not that difficult to my knowledge, or at least they are mostly straightforward.

Hmm, I saw no issue with the NEWT mouse pointer API when integrated it with GraphUI, we did that somewhat together back then AFAIK - consolidating touchpad + mouse to multi-pointer.

But of course, complexity is high when changing something in-between the public API and the platform-code, as side-effects are always possible and auto-testing certain UI feats are hard, especially interaction.
For the latter I used AWT-Robot and our own 'mouse control -> warp' .. still, its a big thing.

Hence hacking now on general simple UI layout and math is a breeze :)

But I will come back to this to fix it .. and I am glad that we have other testers like you here.

Thanks. I think that you see what I mean. I don't want to have to warp the pointer somehow to get relative mouse movements. The information I need are in LibInput but I'll need Udev too for joysticks.

- Resolved the HighDPI w/ AWT and NEWT
  See https://forum.jogamp.org/DPI-scaling-not-working-tp4042206p4042603.html