Marcel, please give me a unique small test (best a unit test)
for validation of this remaining positioning issue.

We use the window unit for position of the parent, 
but looks like that is not accurate.
Parent is a JAWTWindow, from which we fetch its position 
to calculate ours.

Need most simple tests here, if you

For the record:
This issue has been observed on MacOS w/ High-DPI retina 
using a NEWT child window attached to an SWT window using NewtCanvasSWT.

Marcel wrote:

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

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

+++

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.

I am migrating 
https://raw.githubusercontent.com/Bio7/Jogl/master/JoglMacBug/src/newt/JOGL2NewtSWTDemo.java

into our jogl/src/test/com/jogamp/opengl/test/junit/jogl/swt folder 
and make it a unit test

(In reply to Sven Gothel from comment #1)
Of course, in this case the parent is a SWT window, not JAWT :)

commit b2a150a2a9bcf4f821ec84085774168276c108a1

Bug 1421: Demo wrong NEWT Child window position within an SWT TabFolder layout using NewtCanvasSWT on MacOSX with High-DPI Retina

+++

This is the migrated unit test from Marcel earlier.

src/test/com/jogamp/opengl/test/junit/jogl/swt/TestBug1421NewtCanvasSWTPosInTabs.java

Which properly demos the issue at hand.

(In reply to Sven Gothel from comment #6)
TestBug1421NewtCanvasSWTPosInTabs running on MacOS 
without High-DPI Retina also exposed the same positioning issue.

Therefor the position bug is a general issue on MacOS.

commit 741e62820299bc384741d692e2665d22d97c1970
NewtCanvasSWT child on layouted SWT parent only occurs on MacOS, regardless of High-DPI

This issue does not occur on GNU/Linux GTK nor on Windows - tested.

We also have a regression to very related bug Bug 672 com.jogamp.opengl.test.junit.jogl.swt.TestBug672NewtCanvasSWTSashFormComposite

i.e. the GLWindow is now displayed on the left on OSX (Correct is right side like on X11)

(In reply to Sven Gothel from comment #9)
com.jogamp.opengl.test.junit.jogl.swt.TestBug672NewtCanvasSWTSashFormComposite

test shows that 'NewtCanvasSWT.setBounds(..)' is being called w/ position 0/0.
fix for Bug 672 was actually addressing this - propagating the bounds position to NEWT child.

SWT version used is: Version 4.11.0
  
https://download.eclipse.org/eclipse/downloads/drops4/R-4.11-201903070500/

hmm, previously we have used an older SWT < 4 AFAIK
and the child bounds exposed the actual position in relation to the actual root window. I assume all SWT elements on OSX are CALayer

Created attachment 836 [details]
Windows (3000*2000 screen)

Hello Sven,

today I tested the NewtCanvas on Linux (scale 2) and Windows HighDPI.

The result was again an unscaled version of the canvas (see screenshot Windows).

So somehow in an embedded scenario once again the canvas is not scaled.

However if I change, e.g: 

newtChild.setSize(clientAreaWindow.width, clientAreaWindow.height);

to

newtChild.setSize(clientAreaWindow.width*2, clientAreaWindow.height*2);

in the listener and the updatePosSizeCheck the canvas is embedded fine but the pixel scale seems to be still wrong since some information fonts are still tiny.

Is there a way to scale the pixels. I tried to change the pixel scale at various locations to no avail.

With the last post I meant the NewtCanvasSWT which I changed!

When I print the debug message in the NewtCanvasSWT constructor the following output occurs on a Retina display which is obviously wrong:

NewtCanvasSWT: , (Application Thread): newtChildReady false, pixel 0/0 0x0, window 0/0 0x0, scale 1.0/1.0 - surfaceHandle 0x0

I think (my guess at the moment) this is caused e.g., by the getClientArea() method which is called in the constructor. 

Because I open a perspective with an embedded NewtCanvasSWT view the painting has not been finished resulting in 0,0 coordinates, similar to this:

https://stackoverflow.com/questions/51326028/get-size-of-an-swt-view

Whereas the canvas is initialized in the createPartControl method of the view.

However in the updatePosSizeCheck() method the canvas is then initialized and the getClientAreaInPixels() returns the correct size.

When the size is changed in that method (if (sizeChanged)....)
the

newtChild.setSize(clientAreaWindow.width, clientAreaWindow.height);

gets the unscaled width and height.

I would think that the method call:

 newtChild.setSurfaceScale(pixelScale);

would scale everything up to fill the parent canvas

commit 9512a4bbda02002d06fcbb34504c3bea9c7abdc8
Bug 1421, Bug 1358, Bug 969, Bug 672: Generalization of test case TestGLCanvasSWTNewtCanvasSWTPosInTabs (1/2)

commit 1216aa7bc4284e5568d7dd7bbd7f6d9fed27d25b
Bug 1421, Bug 1358, Bug 969, Bug 672: SWTAccessor: Add get[Location|Size]InPixels(..) and getLocationOnScreen()

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.

commit 69db39c035455fc0154006304e7340d825415e99
SWT GLCanvas: Fix NPE in DEBUG mode; NewtCanvasSWT: Resurect comment in setBounds(..)

commit 05b3978d47e304b2e0223bbdf34d393a2e4c7c26
Bug 1421, Bug 1358, Bug 969, Bug 672: Generalization of test case TestGLCanvasSWTNewtCanvasSWTPosInTabs (2/2)

commit 87eeadadfe3a519ca6f6a6688ea854b147eca13b
Bug 1421, Bug 1358, Bug 969, Bug 672: Deleting merged tests (obsolete)

commit 8ab8412568d362b0bf65a40d727ba052a519ea3d
Bump SWT to Release 4.14-201912100610 (jogl/make/lib/swt)

commit abbc95745b69dcd7f5f84c7a56bf32947c23e74d
Bug 1421: OSXUtil: Add GetLocation(..), simply returning the view's frame position

commit 20921924e994e9f612a82009026081a4573b3bdd
Bug 1421: Move Bug 1362 'setBackground(..)' fix before potential 'setNEWTChild(..)'

commit 95fd39e361190c6c23019e1aa5ec21e6fe85fcd3
Bug 1421: Minor cleanup / commenting

commit 0209655c26e9240639c5f0a76ca6ca54ae0584b1
Bug 1421: Minor cleanup / commenting

commit 141fa0fba0f47851f20acfcb078e11659ebc74cc
Bug 1421: Tackle wrong position of TabFolder, SashForm etc 
    
getClientArea() on MacOS produces a 'difficult' result regarding the position,
which usually is returned as zero.
Using a zero position issues the bug w/ SashForm, where the offset doesn't seems
to be covered by the native NSView nor an SWT parent Composition.
    
Then using the getLocation() as is (i.e. the view's frame position)
may also cause issues with the TabFolder, as it includes the tab's trimming.
Here the native NSView 's position includes the tab's trimming,
gladly the parent (TabFolder or a Composition)'s clientArea includes this offset.
    
Therefor, as a testbed - on OSX, getClientArea2(..) returns
- position: getLocation() - getParent().getClientArea().position
- size: getSize()
    
This at least works OK'sh using
- no special layout parent
- TabFolder
- SashForm
    
++++
    
Unit test TestGLCanvasSWTNewtCanvasSWTPosInTabs: Adding 'addComposite' to test matrix.
'addComposite' wraps our GLCanvas or NewtCanvasSWT into a Composite instead of
adding it directly into the layouting parent.
    
It demonstrates an issue with the new test 'test32_NewtCanvasSWTTabSashGLWComp',
i.e. the NewtCanvasSWT is shown on the left as the SashForm's offset is being dropped.
    
Summary:
- No more issues with High-DPI pixelScale observed!
    
- GLCanvas is being most well layouted, no issues in tests
    
- NewtCanvasSWT may show severe positioning issues -> test32_NewtCanvasSWTTabSashGLWComp
- NewtCanvasSWT always shows a small positioning offset into the lower-right corner w/ overlapping
- NewtCanvasSWT overall positioning is not perfectly understood
- NewtCanvasSWT misses to hide the NEWT child when changing tabs in TabFolder

(In reply to Marcel Au from comment #11)
it is not helping to mix up issues here.

i.e. now you write about Linux/Windows 'scale factors' within SWT.
Your comment 11 to comment 16 seem to cover non MacOS platforms, i.e. Linux/Windows - and also not positioning but scaling.

We need to track these in a separate bug here.

One step at a time.

++++

First of all please validate work of comment 17 for this issue

(In reply to Sven Gothel from comment #18)
reopened Bug 1358

(In reply to Sven Gothel from comment #17)
Please test and reproduce issue using comment 17 work,
particularly the unit test TestGLCanvasSWTNewtCanvasSWTPosInTabs

(In reply to Sven Gothel from comment #17)
https://jogamp.org/deployment/v2.4.0-rc-20200106/

Moving further MacOS (High-DPI) NewtCanvasSWT fixes to version 2.4.1

to test using com.jogamp.opengl.test.junit.jogl.swt.TestGLCanvasSWTNewtCanvasSWTPosInTabs
with our builds, e.g. fat jar files, one may do the following:

GNU/Linux X11 amd64:
user@host:/JogAmp/builds/v2.4.0-rc-20200106$ java -cp /JogAmp/jogl/make/lib/swt/gtk-linux-x86_64/swt.jar:fat/jogamp-fat-test.jar \
com.jogamp.opengl.test.junit.jogl.swt.TestGLCanvasSWTNewtCanvasSWTPosInTabs
 
On MacOS amd64:
user@host:/JogAmp/builds/v2.4.0-rc-20200106$ java -cp /JogAmp/jogl/make/lib/swt/cocoa-macosx-x86_64/swt.jar:fat/jogamp-fat-test.jar \
com.jogamp.opengl.test.junit.jogl.swt.TestGLCanvasSWTNewtCanvasSWTPosInTabs 

Hope it helps a little

(In reply to Sven Gothel from comment #23)
Otherwise .. build it:

https://jogamp.org/gluegen/doc/HowToBuild.html
https://jogamp.org/cgit/joal.git/tree/README.txt
https://jogamp.org/jogl/doc/HowToBuild.html

then you will also find my build and test scripts 
in the scripts subfolder below <project>/make, i.e. 
jogl/make> scripts/make.jogl.all.macosx.sh (build macos)
jogl/make> scripts/make.jogl.all.linux-x86_64.sh (build linux amd64)

issue one unit test:
jogl/make> scripts/tests-x64.sh (linux amd64)
jogl/make> scripts/tests-osx-x64.sh (macos)

to change the unit test setting and select it:
jogl/make> vi scripts/tests.sh

Hello Sven,

I tried to execute the tests with your recipe:

On MacOS amd64:
user@host:/JogAmp/builds/v2.4.0-rc-20200106$ java -cp /JogAmp/jogl/make/lib/swt/cocoa-macosx-x86_64/swt.jar:fat/jogamp-fat-test.jar \
com.jogamp.opengl.test.junit.jogl.swt.TestGLCanvasSWTNewtCanvasSWTPosInTabs 

However I got an Invalid thread access for SWT.

Seems to fail here according to error:

https://github.com/sgothel/jogl/blob/141fa0fba0f47851f20acfcb078e11659ebc74cc/src/test/com/jogamp/opengl/test/junit/jogl/swt/TestGLCanvasSWTNewtCanvasSWTPosInTabs.java#L509

(In reply to Marcel Au from comment #25)
Implying all other tests went through?

Assuming you have adapted the proper path in your commandline of course (swt and our fat jar), otherwise you couldn't even launch the test.

OK, tested this way on OSX myself, i.e.

'java -cp ../../jogl/make/lib/swt/cocoa-macosx-x86_64/swt.jar:fat/jogamp-fat-test.jar com.jogamp.opengl.test.junit.jogl.swt.TestGLCanvasSWTNewtCanvasSWTPosInTabs'

and I get a 'wonderful' SWTException: Invalid thread access 
as we don't start on the AppKit thread and the unit test
is lazy not issuing these calls there :)

1) test01_GLCanvasTabPlainGLDirect(com.jogamp.opengl.test.junit.jogl.swt.TestGLCanvasSWTNewtCanvasSWTPosInTabs)
org.eclipse.swt.SWTException: Invalid thread access
        at org.eclipse.swt.SWT.error(SWT.java:4720)
        at org.eclipse.swt.SWT.error(SWT.java:4635)
        at org.eclipse.swt.SWT.error(SWT.java:4606)
        at org.eclipse.swt.widgets.Display.error(Display.java:1112)
        at org.eclipse.swt.widgets.Display.createDisplay(Display.java:853)
        at org.eclipse.swt.widgets.Display.create(Display.java:837)
        at org.eclipse.swt.graphics.Device.<init>(Device.java:132)
        at org.eclipse.swt.widgets.Display.<init>(Display.java:736)
        at org.eclipse.swt.widgets.Display.<init>(Display.java:727)
        at com.jogamp.opengl.test.junit.jogl.swt.TestGLCanvasSWTNewtCanvasSWTPosInTabs.runTestInLayout(TestGLCanvasSWTNewtCanvasSWTPosInTabs.java:180)


+++

Fix is to launch the test on AppKit thread:

'java -cp ../../jogl/make/lib/swt/cocoa-macosx-x86_64/swt.jar:fat/jogamp-fat-test.jar -XstartOnFirstThread com.jogamp.opengl.test.junit.jogl.swt.TestGLCanvasSWTNewtCanvasSWTPosInTabs'

and then the test actually launches.

Sorry about that, forgot about those MacOS SWT details, as I have abstracted them away in the build-text.xml unit test and scripts/tests.sh file.

(In reply to Sven Gothel from comment #26)
'java -XstartOnFirstThread -Djava.awt.headless=true -cp ../../jogl/make/lib/swt/cocoa-macosx-x86_64/swt.jar:fat/jogamp-fat-test.jar com.jogamp.opengl.test.junit.jogl.swt.TestGLCanvasSWTNewtCanvasSWTPosInTabs'

^^ I also use '-Djava.awt.headless=true' for non AWT tests FYI

Ok Sven,

so far this test works for me.

Just for your information in my app the embedded view coordinates are correct calculated from the SWT side using the SWT method toDisplay.

In the class NewtSWTCanvas in the method getclientArea2() I had to change the calculation for the position to:

final org.eclipse.swt.graphics.Point l = getParent().toDisplay(getLocation());

and at the end of the method the right y-position would be (according to the SWT toDisplay method which seems to be correct - I measured it):

r.x = l.x;     //- parentClientArea.x; // FIXME +1?
r.y = l.y;      //- parentClientArea.y; 

However the y-position is somehow wrongly displayed then (ca. 135 pixels to low).
It's seems to dishonor the correct SWT toDisplay y-corrdinates.

Could it be that the method:

newtChild.setPosition(clientAreaWindow.x, clientAreaWindow.y);

calculates the y-position wrong in an embedded layout (inversed coordinates or something)?

It's strange that the tests works OK.

(In reply to Marcel Au from comment #28)
"It's strange that the tests works OK."

They did not :)

Finally I went from 'coast to coast', i.e. reviewing the whole OSX NSView and NSWindow layout and position (on screen).
I then compared it what we use with NEWT on OSX and voila, there is the issue at hand: We missed the 'view <-> window' coordinate translation as on pure NEWT, we only have 1-view to 1-window, hence the same.

Not so w/ SWT as only the Shell owns the NSWindow and the rest are sub-views.

See following commit ..

+++

commit 12bbb049b716282321c979ae78918801ef071884

Bug 1421, Bug 1358, Bug 969, Bug 672: Fix NEWT's coordinate conversion on MacOS (fixes NewtCanvasSWT on SWT positioning)
    
Newt's OSX Window consist out of NSView wrapped up within its own NSWindow.
It's position is being set via its NSWindow's client-area position on screen (frame),
which we derive from NSView's client-area position.
    
When NEWT reparents into a new 'window',
on OSX it uses the parent's NSView and its NSWindow
to attach its own NSView and NSWindow as a subview and childwindow.
  
SWT's OSX implementation uses NSView's for each Compositor,
but an individual NSWindow is only established for the Shell (Window).
    
An oversight in Nativewindow and NEWT's coordinate translation:
'top-left view <-> top-left screen'
by missing the 'view <-> window' translation caused this whole issue.
    
The oversight occured as NEWT's 'view <-> window' translation
had no impact due to its 1-view to 1-window mapping.
    
Fixing the coordinate translation resolves the mess
for SWT and for potential other toolkits on OSX.
    
NewtCanvasSWT behaves same on OSX as on X11 etc finally.

One more to fix TabFolder etc .. (Hide/Show)

commit 39af5ca418d0db9669aca5db77fa47e801e2a1d9

    Bug 1421 Related: Handle SWT Events: Activate (focus), Show and Hide.
    
    Show and Hide handling resolves TabFolder layout,
    i.e. hiding the 'hidden' and showing the current tab.

I will kick off unit testing soon for validation.
This should allow us to close this issue for good.

Sven, great to hear. 

As soon as a built is ready I will test it.



Just one note to the highDPI implementation on Window and Linux.

With the last built the canvas still occupies only 1/4 of the swt canvas.

I had to correct the scale at three positions where I scale up the NewtCanvasSWT:
 
int scale=(int)DPIUtil.getDeviceZoom()/100;


at the three positions where the call to newtChild.setSize(...) occurs.  I correct the implementation with:

newtChild.setSize(clientAreaWindow.width*scale, clientAreaWindow.height*scale);

(In reply to Marcel Au from comment #31)
https://jogamp.org/deployment/v2.4.0-rc-20200113/

Re 'fake' high-dpi for Linux and Windows, 
please be so kind and make same statement in Bug 1422.

Best a patch file (diff -Nur), even better a git pull request or a git patch,
so we can have you as a contributor.

Also please mark this for the selected platforms, all non !SWTAccessor.isOSX (?)
and add a comment re 'Bug 1422 Hack .. something'.
Thank you.

(In reply to Sven Gothel from comment #30)

Hello Sven,

I tested the implementation on Mac a bit.

The positioning on Mac now works fine.


However for  Bug 1421: 

If I switch the tabs in the tab example I see at first that the hiding works. But when I activate the tab again and then resize the shell the
NewtCanvas will be hidden. 

When I switch the tabs again the canvas reappears.

In addition when I move the Shell the canvas stays at the poition and doesn't follow the shell as long as I don't switch the tabs which corrects the location again.

Somehow it seems that the parent get's lost.

In my RCP I tested it, too.

The positioning now works, too.

However, when I switch the perspective the canvas stays visible on top of the views and is not hidden.

When I try set the canvas invisible and visible in a view listener (as already described) it will be hidden but not activated when I set it to visible(true). The same for the size.

Once again I can only guess that the canvas looses the parent.

When I switch to fullscreen mode the top left of the tab client area is used and not the monitor top left.

These are my current findings.

(In reply to Marcel Au from comment #33)
Good, so 1421 is done. 

Now we have 1422 left (your Bug 1421 comment 31)
and on OSX (only I assume):
- moving 
- resize issue (re-layout)

(In reply to Sven Gothel from comment #34)
Hello Sven,

I tested a little bit more and installed an activate, deactivate view listener in my RCP view. 

With this at hand I could reproduce the issues described for the simple tab example which is really a progress since I can deactivate and activate the newt window.

I had to wrap it in a display.asyncExec, used the newtChild.setVisible(false/true) and then it works exactly like the tab example (it is displayed as long as it has focus - and this error occurs only after a first deactivate activate event).

I think there are now the two issues I described before.

So for my RCP view (the same as the tab example):

If the focus is lost the canvas is not displayed. If have focus (if I click on the canvas) the newt window is shown again.

In addition when I detach the view and move it the canvas stays at the position and doesn't follow the detached view as long as I don't resize the view which corrects the location again.

Another strange error is the sometimes inconsistent behaviour of the y-position 

Sometimes the deactivate and activate works and sometimes not.

Sometimes the y-coordinate increases out of the display bounds if I set the
canvas visible on activate.

Then the following getBounds() are printed (increading y-coordinate on activate events):

Here printed several results on activate:
0,0,996x693
0,900,996x693
0,2700,996x693
0,2700,996x693
0,2700,996x693

This could happen if  I start my application several times.
Then it works or not as described in the previous post.

(In reply to Marcel Au from comment #35)
Perfect Marcel, we are getting much closer.

NEWT's OSX impl. erroneously issued 'orderOut' for setVisible(false),
however, OSX >= 10.7 does detach the child window from parent here.

This not enough, if manually detaching (hide) and attaching (visible)
the child window to SWT's parent: We get quite some issues as shown 
in the respective comments. Like exceptions for method not implemented in SWT's object and such.

Further, the parent window handle changes under the hood using SWT here,
so our own tracked handle is no more valid.

Resolution to this mess is to implement a 'Fake invisible child window':
1) move it out of sight 2x viewport size to origin
- viewport covers all displays
- 2x b/c we need to cover the potential window move ;-)

2) ignore position updates while being invisible child

3) surely still mark it invisible

commit d92dc518eb891f2d125a8136efd6ed603d74a6e9

Bug 1421: NEWT OSX Invisible: Refining child window visibility setting, commenting on child-window orderOut

Actual small change is to have child-NSWindow to use '[myWindow orderWindow: NSWindowAbove relativeTo:..'
instead of 'orderFront' in creation and use the simple 'orderFront' to set a top-level NSWindow visible.

Adding comment why we can't use 'orderOut' on child-NSWindow setting it invisible,
this is due to OSX 10.7 changes and testing detaching the child-window from its parent
causes havoc w/ SWT at least.
Hence we only issue 'mWin orderWindow: NSWindowOut relativeTo:..]' and the result is
having the child-NSWindow below the application.

This in turn will make it visible again when moving the application around,
as this child-NSWindow will no more follow the position.

Suggestion is to have this 'fake invisible' child-NSWindow to be moved
out of the overal viewport (all screens).

commit abc833e8e3763b1477e8e7c22a04b6fecf97cf20

NEWT OSX/IOS WindowDriver: Minor cleanup of local var usage (prefer reuse); reconfig: Only orderOut w/ valid window-handle

commit fcad9bd8856f4058925389854a31ec265b94d5e0

NEWT OSX MacWindow.c: Add parentWindow to DBG_PRINT

commit 6d341e110912f9085194cb94ba6f6c358104ee71

Bug 1421: NEWT OSX Invisible: Fix orderOut0 re commit d92dc518eb891f2d125a8136efd6ed603d74a6e9

We also cannot use 'mWin orderWindow: NSWindowOut relativeTo:..]' as it also removes the child-NSWindow from its parent like 'orderOut'.
Hence only use 'orderBack' to keep the relationship inplace.

Fake invisible child window is in progress,
i.e. moving it out of the overal viewport (all screens).

commit 85b332e0954af4afc9225eb84d758bee834dc497

Bug 1421: NEWT OSX Invisible: Implement 'Fake invisible child window'

'Fake invisible child window' is implemented by simply moving the window out of sight (viewport).

- orderOut0 needs to use '[mWin orderWindow: NSWindowBelow relativeTo:..' parentWindow
  instead of '[mWin orderBack:..', otherwise the whole parent application gets invisible w/ SWT ;-)

- NewtNSWindow may also needs to use parent's Screen instance if moved offscreen,
  as the own Screen is invalid (zero size) in this case.

- WindowDriver: Adding special treatment for 'Fake invisible child window' (tagged as such):
-- reconfigureWindowImpl: setWindowClientTopLeftPointAndSize0(..) will be called
   using the viewport's max position -> out of sight.
-- screenPositionChanged: ignore the 'new' position
-- sizeChanged: ignore the 'new' size

This sensitive NEWT change set shall benefit other toolkits being used as parentWindow
besides SWT, as this behavior is the same across MacOS.

commit f56adf14deadd4ee8f434ea1293e27bcafdf2a90

NEWT.Window: Add 'StringBuilder append(StringBuilder sb)' supporting building custom efficient presentations

commit 9263c27e98cb85b5cdff301dcb943a5a40ae6c3b

Bug 1421: NEWTCanvasSWT: No action on SWT.Activate, use SWT.FocusIn. Also remove all SWT listener on dispose.

Additionally print more details about the newtChild's state in DEBUG mode.

commit cfdfa7716422e76123c911a8f70bf84a682875e0

Bug 1421: Conclude OSX: Forward SHOW and HIDE events to NewtCanvasSWT instances if 'below notification threshold'

'below notification threshold' here is simply being a child SWT Control of like a Composition or SashForm etc
where these events won't get propagated.

commit 6c9eedf03a196d8718ddccbb47c0166c7c6267b8

Bug 1421: NEWT OSX Invisible: Refine 'Fake invisible child window' off-viewport position

Ensure it stays out of sight by moving it to 2x width/height of viewport.
Otherwise one could see the child window moving from lower-right to upper-left ;-)

commit 88cc287a47066c81ee0b385e2e0ca96f027286b3

TestGLCanvasSWTNewtCanvasSWTPosInTabs: Only use 1 Animator to easy example code

Otherwise one would want to pause the Animator instance for the hidden GLWindow,
otherwise such animator with zero visible drawables will become a CPU hog.

(In reply to Marcel Au from comment #35)
As you can see in commit cfdfa7716422e76123c911a8f70bf84a682875e0
we still have to forward the SHOW and HIDE event to the NewtCanvasSWT instance 
IF it is not the top element of CTabItem, e.g. a child within a Composition or the SashForm.

But it looks like .. that's all to do for customizing the user code.
Sure, if you find a good way to add this to NewtCanvasSWT in a general 
form - we should add such.

Now let's see to Bug 1422

https://jogamp.org/deployment/v2.4.0-rc-20200115/

(In reply to Sven Gothel from comment #40)
Unit test TestGLCanvasSWTNewtCanvasSWTPosInTabs works w/o flaws
as manually tested:

'java -XstartOnFirstThread -Djava.awt.headless=true -cp ../../jogl/make/lib/swt/cocoa-macosx-x86_64/swt.jar:fat/jogamp-fat-test.jar com.jogamp.opengl.test.junit.jogl.swt.TestGLCanvasSWTNewtCanvasSWTPosInTabs'

+++

Adding arguments for manual test:

''java -XstartOnFirstThread -Djava.awt.headless=true -cp ../../jogl/make/lib/swt/cocoa-macosx-x86_64/swt.jar:fat/jogamp-fat-test.jar ' 

plus:

For the test21 using GLWindow directly in CTabItem
'com.jogamp.opengl.test.junit.jogl.swt.TestGLCanvasSWTNewtCanvasSWTPosInTabs -time 1000000 -test 21'

For the test22 using GLWindow within Composite, which gets in CTabItem
'com.jogamp.opengl.test.junit.jogl.swt.TestGLCanvasSWTNewtCanvasSWTPosInTabs -time 1000000 -test 22'

You may also play the debug properties before the test class:

'-Dnativewindow.debug.SWT -Dnewt.debug.Window -Djogl.debug.GLCanvas com.jogamp.opengl.test.junit.jogl.swt.TestGLCanvasSWTNewtCanvasSWTPosInTabs -time 1000000 -test 21'

Hello Sven,

thanks again for taking the time to fix the bugs.

I tested the new implementation on MacOSX.

Now the hiding and activating works as it should which is really great.

In my RCP view I have to use the view listeners (as you already noted).

Just two outstanding issues.

1. If I switch to fullscreen (GLWindow.setFullscreen()) the top left display starts at the 0,0 coordinates of the embedded view and not of the monitor 0,0 coordinates. I tried to correct this with the newTChild.setPosition method but this had no effect.

2. If I detach the view the NewtCanvas stays behind the detached view (in the last
built the canvas stood above the detached view).

When I drag the detached view to another location I have to resize the view so that the canvas follows but still stands behind the detached view.

I think the second problem is not so essential but it would be nice to correct the fullscreen coordinates.

(In reply to Marcel Au from comment #42)
Good - I first will close this Bug.

How about Bug 1422 (fake DPI scale, as I call it)?

Please open new bug reports for the other issues.

*** Bug 1378 has been marked as a duplicate of this bug. ***

Verified by Marcel Au, comment 42

(In reply to Sven Gothel from comment #43)

Fullscreen bug opened here:

https://jogamp.org/bugzilla/show_bug.cgi?id=1423

(In reply to Sven Gothel from comment #43)
Detached view bug report opened here:

https://jogamp.org/bugzilla/show_bug.cgi?id=1424

(In reply to Sven Gothel from comment #41)

Hello Sven,

I found a very interesting behaviour on MacOSX which is an addition to comment 42.

As I already described when I detach the window on MacOSX the NewtCanvasSWT is hidden behind the detached view. 

But when I now enter fullscreen and then instantly exit fullscreen the NewtCanvasSWT  is attached on top of the detached view and it works as expected (resizing, change location).

Now when I attach the view to the perspective again I once more have to enter/exit fullscreen before I can resize the view again embedded in the perspective. 

If I don't use enter/exit fullscreen after I attach the view to the perspective  the NewtCanvasSWT will completely hidden when I resize the view (if I don't resize the view it stays visible).