Bug 1358

Commit ca7f0fb61b0a608b6e684a5bbde71f6ecb6e3fe0

Christian reported this bug and described multiple pathways.

This change usese the following:
- access to getClientAreaInPixels w/ fallback of
- DPIUtil.autoScaleUp(getClientArea())

I hardly have tested this on Linux/GTK, even though I use a High DPI monitor,
maybe just because of it and Eclipse _poor_ state of proper UI presentation.

Christian: Please test this .. if buggy, reopen quick for release 2.4.0

SWT/GTK High-DPI is a PIA: 
- GDK_SCALE renders offscreen and scales the image (wow & ugly)
- GDK_DPI_SCALE works at least on the fonts properly
- swt.autoScale is pretty much like: What will be scaled?
  It scales some icons in Eclipse, not fonts and result in Eclipse 
  looks horrible.

Maybe I just made this patch to vent about this poor state of things.

Notable: KDE looks great and uses DPI, firefox some GDK_DPI_SCALE equivalent (OK)

One also wonders why there is only a single scale dimension, where DPI differs x/y!
But enough of my rant :)

Marcel reported: <http://forum.jogamp.org/JOGL-2-4-built-Newt-SWT-MacOSX-Wrong-Canvas-Size-tp4040233.html>

"when I execute my JOGL SWT Newt example with the latest JOGL built on MacOSX I see a wrong size and location calculation of the NewtCanvas, see screenshot below:

<image>

Example Source as Eclipse project with libraries here (Main class = JOGL2NewtSWTDemo):

https://github.com/Bio7/Jogl/tree/master/JoglMacBug

It seems as if the width and the height of the newt canvas is exactly twice as big as the parent swt canvas size (Retina related?).

Also the top left 0,0 coordinates seems to be wrong (besides overlapping bug described in bug 1378).

Is there a way how I can change the size and origin of the NewtCanvasSWT at startup?

I tried, e.g., setSize method to no avail."

Marcel, was it this commit ca7f0fb61b0a608b6e684a5bbde71f6ecb6e3fe0
of Bug 1358 causing the regression? 

We may continue debating it in bugzilla and yes,
would be great to have this finally fixed.

Hello Sven,

I searched the commit on Github and found a statement from Alexis Drogoul:

https://github.com/sgothel/jogl/commit/ca7f0fb61b0a608b6e684a5bbde71f6ecb6e3fe0

Which leads to a Gama platform about this issue.

Seeing the screenshots they had the same issue and already solved it?:

https://github.com/gama-platform/gama/issues/2628#issuecomment-488711019

They apparently used the DPIUtil method in their source and scale the canvas down,
see:

https://github.com/gama-platform/gama/commit/19e151912132c56e11011e39f0d06f91fab1bb6f#diff-1c19260c8efbe045d1e998c3f4ecdfd4

So my guess is thst the method updatePosSizeCheck (called from setBounds) in class NewtCanvasSWT.java must be scaled down for MacOSX Retina.

see:

https://github.com/sgothel/jogl/commit/ca7f0fb61b0a608b6e684a5bbde71f6ecb6e3fe0#diff-ca3c269cf40e4cd57c365cbfd880c8c5

(In reply to Marcel Au from comment #4)
https://github.com/sgothel/jogl/commit/ca7f0fb61b0a608b6e684a5bbde71f6ecb6e3fe0#commitcomment-33397325

AlexisDrogoul commented on ca7f0fb on May 3, 2019

Hi,

One issue of this commit is that the width and height of canvases are now systematically doubled when they are passed to reshape(...), as least on macOS with a Retina display. See for instance gama-platform/gama#2628 (comment), where all the displays are now wrong.

Was this the intended behaviour of this commit ? In that case, how do we come back to the "old" values ? Should we use some downscaling of DPIUtil ? Use another field of the Drawable ?

Thanks in advance for any clue,
Cheers
Alexis

(In reply to Marcel Au from comment #6)
> So my guess is thst the method updatePosSizeCheck (called from setBounds) in 
> class NewtCanvasSWT.java must be scaled down for MacOSX Retina.

Finally reviewed the code .. and gladly it rings a bell :)

'getClientAreaInPixels()' properly returns the size in pixel units,
either using swt_scrollable_clientAreaInPixels or DPIUtil.

    pixel-unit size = window-unit size * dpi-scale

Now this commit ca7f0fb61b0a608b6e684a5bbde71f6ecb6e3fe0 
does one thing wrong IMHO: Using the pixel-unit size for 
setting up the NEWT child window 'eh? :)

So while his pixel-unit size should work well for being using as
surface-size in pixel units for like GL reshape,
it would artificially double scale up the window :)

Now I have to dig out my MacOS Book w/ DPI screen and test this, 
partially reverting using window-units for window size operations.

Sounds reasonable?
Maybe you can test as well.

Hello Sven,

sounds reasonable. I would be happy to test the changes.
will you make the changes available as a new build?

(In reply to Marcel Au from comment #9)
yes, I will kick-off another RC .. 
Will do this regularly on changes pre release for testing.

Split changes in most atomic commits to separate their individual semantics:

+++

commit e6d53e29f05a6928192f6c4a988b2aa558be8d65

    Bug 1358: Add OSXUtil.GetWindowPixelScale(..)
    
    It is now possible to retrieve the pixel scale [NSWindow backingScaleFactor]
    after native creation by NEWT - as we have changed the lifecycly (all-in-one native method on AppKit)

+++

commit 3b60cb464cea77a22f866155c14c8786dea360ba

    Bug 1358: NewtCanvasSWT High-DPI: Use window-units where required instead of pixel-units
    
    Commit ca7f0fb61b0a608b6e684a5bbde71f6ecb6e3fe0
    did one thing wrong: Using the pixel-unit size for
    NEWT child window operations where window-units are required.

+++

commit fb211581fefc994d1458a2a74801dfb937170f39

    Bug 1358: NewtCanvasSWT High-DPI: Propagate pixelScale to NEWT-Child and utilize it for convertTo*Units(..)
    
    Detected pixelScale on SWT should be propagated to the NEWT Child
    using 'newtChild.setSurfaceScale(pixelScale)' to allow an impact.
    
    Also utilize computed pixel for converTo*Units(..) implementation.

+++

commit 7d7d4e4f194ed25dc8b450e13ab67020c607445b

    Bug 1358: MacOS NEWT WindowDriver / NewtCanvasSWT High-DPI:
    
    Even w/ commit fb211581fefc994d1458a2a74801dfb937170f39, propagating the SWT pixelScale to NEWT-Child,
    hasPixelScale was never updated via updatePixelScale() through native callback [NSView viewDidChangeBackingProperties]!
    
    [NSView viewDidChangeBackingProperties] not being called on [created] child windows (NewtCanvasSWT)
    confused the overal pixelScale state, i.e. no hasPixelScale update via updatePixelScale(..).
    
    This change explicitly queries OSXUtil.GetWindowPixelScale(handle) (commit e6d53e29f05a6928192f6c4a988b2aa558be8d65)for:
    
    1) updateMaxScreenPixelScaleByWindowHandle(..), which now updates the actual hasPixelScale after native creation
    
    and for
    
    2) setSurfaceScale(..), which directly calls updatePixelScale(..) with the queried actual pixelScale
    instead of relying on the native callback [NSView viewDidChangeBackingProperties].

+++

It goes w/o saying, the last commit was the most annoying issue at hand.
But I hope the explicit call to updatePixelScale(..) not relying on the 
NSView callback should resolve other issues as well.

I have tested using: com.jogamp.opengl.test.junit.jogl.swt.TestNewtCanvasSWTGLn

(In reply to Marcel Au from comment #9)

Its included here:

JogAmp Jbeil RC Build 2.4.0-rc-20200104

<https://jogamp.org/deployment/v2.4.0-rc-20200104/>

Changes to previous RC:

...

3) Bug 1358 <https://jogamp.org/bugzilla/show_bug.cgi?id=1358>
- fixed I hope, waiting for validation 

...

Created attachment 835 [details]
Screenshot Wrong Position

Hello Sven,

the size now works correctly. 

However if the NewtCanvasSWT is embedded in a tab the location is displayed in a wrong location.

The location position only works if the canvas is directly embedded in a composite.

In the example I have given this can be seen in a wrong y-location (see screenshot
in forum message whereas the location is not directly below the tab).

If the window is tiled it is far more wrong (see afore attached screenshot).

With my example I mean of course the example linked in the forum message:

http://forum.jogamp.org/JOGL-2-4-built-Newt-SWT-MacOSX-Wrong-Canvas-Size-td4040233.html

The afore attached screenshot in this bugzilla forum shows the consquences of  the wrong position calculation in an embedded application layout.

Somehow the correct corner coordinates of the embedded canvas are not calculated.

(In reply to Marcel Au from comment #14)

Therefor I can close this issue here: Scaling size.
The original commit fixing Christian's original report (comment 1) 
is still intact and valid and fixes served here also complete
my earlier patch: See comment 8 and comment 11.

We continue with Bug 1421: Scaled child window position.

jogl commit 8caf3fab68dc890855961d22cb235d1c8f5c52c6

Bug 1358: GLCanvas: Call new OSXUtil.SetWindowPixelScale(..) when GLCanvas gets realized on MacOS
    
This fixes GLCanvas's High-DPI scaled size issue on MacOS of Bug 1358.

Marcel found still issues on Windows and Linux re scaling,
see Bug 1421 comment 11 through Bug 1421 comment 16.

Please test and reproduce issue using Bug 1421 comment 17 work,
particularly the unit test TestGLCanvasSWTNewtCanvasSWTPosInTabs

replying to Bug 1421 comment 16

There is no native surfaceScale on linux or windows at all,
only on MacOS. Therefor NEWT has no setSurfaceScale(..) impact 
on these platforms.

The scale factor on linux and windows is artificial
and one always gets the pixel-unit via GTK/GDK and native.
This is also demonstrated in SWT's implementation, 
which simply does a dump autoScaleDown of pixel-unix -> window-unit.

(In reply to Sven Gothel from comment #20)
commit 557f3d57cc2ca60678fe87df4b4a9c99c016e575

Bug 1358: Merely simplifying the non MacOS getClientAreaInPixels() code path
    
This also demonstrates that on non MacOS, SWT's scale-factor is artificially imposed
on the actual pixel-units, as SWT's getClientArea() is simply returning:
  DPIUtil.autoScaleDown(getClientAreaInPixels())

(In reply to Sven Gothel from comment #21)
This artificial scaled-down window-unit clientArea,
should have no impact on NEWT Windows whatsoever
as we use clientAreaPixels for size and don't change 
the position for non-MacOS.

(In reply to Sven Gothel from comment #22)
Closing this issue again.

We shall create a new bug entry which may reference Bug 1358 and Bug 1421 
to tackle further open issues, like the mapping of SWT's dpi-scaling
on platforms other than MacOS where it is not actually implemented
in the native toolkits: Windows and Linux GTK.

Both latter may have high level artificial dpi-scaling for 
so called unaware applications to map the 75 dpi on 150 dpi or higher.
However, this is worth a new bug entry as we have exhausted the original issue reported here.

Hi,
we reported an issue with Jogl 2.3.2 and the com.jogamp.opengl.swt.GLCanvas, when it is resized only a part of the canvas is redrawn on Linux platforms: https://jogamp.org/bugzilla/show_bug.cgi?id=1395.
Following Julien Gouesse's advice, we tested 2.4.0-rc-20200306 thinking that the fix of this bug fixes our bug too (forum thread: http://forum.jogamp.org/Resizing-GLCanvas-does-not-redraw-immediately-td4040590.html).
Unfortunately the bug is still there :(
Maybe bug 1395 should be added to the list of issues regarding JOGL/SWT Windowing/Surface Interoperability (bug 674), what do you think ?