Posted by Sven Gothel on Nov 08, 2012; 5:37pm
URL: https://forum.jogamp.org/Thread-blocking-issue-with-AWT-but-not-NEWT-on-OSX-tp4026674p4026832.html

On 11/08/2012 06:09 PM, ac [via jogamp] wrote:
> Great, thanks for the updates and fixes.

Here is the fixing commit for OSX Java7 (should also fix behavior of other OS)
regarding GLAutoDrawable disposal w/o a created context - and JAWT locking w/o native peer:
   <http://jogamp.org/git/?p=jogl.git;&a=commit&h=d0f91a8ed17fbb1a7b56511c4e53a29e576f01af>

The unit tests contain a manual workaround, if required, see detection here:
  <http://jogamp.org/git/?p=jogl.git;a=blob;f=src/test/com/jogamp/opengl/test/junit/jogl/awt/TestGLCanvasAWTActionDeadlock01AWT.java;h=c51972c39b47afa9c1bf334d8127358666a5ed36;hb=d0f91a8ed17fbb1a7b56511c4e53a29e576f01af#l122>

>
> I have a more general question: would you recommend moving over to NEWT? Right
> now I implemented both paths (AWT/NEWT) in the Processing renderer, but keep
> using AWT mainly out of fear of compatibility issues... However, adding
> support for devices like the Raspberry Pi requires NEWT, as some tests by
> Xerxes Ranby seem to indicate.

Well, even though we try to be bug free even for native AWT / SWT,
we prefer NEWT due to it's more simple and straight forward implementation
and much less dependencies. Also the threading behavior is much better w/ NEWT,
even if used w/ AWT or SWT (-> NewtCanvasAWT and NewtCanvasSWT).
Also see: <http://jogamp.org/jogl/doc/NEWT-Overview.html>

Further more, there is no AWT/SWT on [headless] devices, only NEWT,
read Android and Raspberry Pi (currently).
[The Raspberry Pi is a special case though, and we may have JAWT support some day
when X11 EGL support is enabled]

However, if there is JOGL/AWT support, there is always NEWT support
but not the other way around :)

Hence in the long run to support most devices I would do:
  - Use NEWT incl. it's event listeners for basic implementation
  - Use NewtCanvas[AWT/SWT] if it must be added to such a UI

This migration path has been followed by professional and complex applications,
which were the actual driver of it (C3D CAD module).

The latter application runs well on Android now as well,
while being able to reuse the whole GL and NEWT module and stripping off AWT :)

>
> Also, and as a purely speculative thought at this point: since JOGL fully
> supports the creation of FBO-supported offscreen surfaces, wouldn't be
> possible to create a purely headless OpenGL context, which then could be drawn
> into the native window? Wouldn't this solve all the windowing and event
> handling issues?

Well, as you can see in the GLFBODrawableImpl, we still use a dummy window/surface handle
since a GL context is not complete otherwise. But that's not a real problem.
On EGL we use a pbuffer btw :)

Short answer, we now can utilize it - yes.
Now it's used for OSX CALayer.
- We could also use it for Raspberry Pi to complete AWT.
- We could also use this path for the Swing based GLJPanel.

Both cases would require us to composite the the offscreen pixels into the
used native components visible area, e.g. into AWT's canvas for example.

Otherwise many folks would like to still use plain onscreen rendering
via NEWT's GLWindow and AWT GLCanvas if supported.
The compositing windowmanager may force offscreen here as well,
but then they usually allow exclusive fullscreen mode without that!

Note that windowmanager on Windows and X11, compositing transparent surfaces is done
API transparent via their 'normal' API, unlike OSX w/ CALayer :)

So while tools and techniques are available and partially used
they are not the answer for everything.

The offscreen windowing handling incl. events etc, is actually more complicated
since all responsibility is on us here.
We have a bug in AWT->NEWT event translation for example .. and there are other issues.

So .. let's say it's quite complex - yes,
but we cannot force offscreen FBO and it's complexity to all our users,
especially not w/ NEWT and on mobile devices.

~Sven