Some issues using NEWT

Thanks for the clarifications.

Just to make sure I got things right: the integration is seamless as long as the "real" application activity ([user:a2] to follow your notation) uses NEWT, i.e. it is a subclass of NewtBaseActivity and encapsulates the rendering code within a GLEventListener, is this correct?

I guess this defeats the purpose of your Android version of JOGL, but I will ask nonetheless: is it possible to just to use the GL bindings offered by JOGL without switching to its NEWT windowing mechanism?

The JogAmp APKs would need to be installed by the end user separately from the market (although just once), right?

Finally, and this is more like a separate issue: I noticed that doing incremental drawing on a GLSurfaceView (i.e.: not clearing the color buffer at the beginning of each frame, which is useful for instance for drawing applications) is not possible, at least without resorting to more advanced techniques (offscreen rendering via FBOs). Given how double buffering is handled in Android, you would get screen flickering if glClear(GL_COLOR_BUFFER) is not called at the beginning of each frame, instead of just showing the contents of the last frame. Is this the same when using NEWT on Android?

On 03/22/2012 04:26 PM, ac [via jogamp] wrote:
>
>
> Thanks for the clarifications.
>
> Just to make sure I got things right: the integration is seamless as long as
> the "real" application activity ([user:a2] to follow your notation) uses
> NEWT, i.e. it is a subclass of NewtBaseActivity and encapsulates the
> rendering code within a GLEventListener, is this correct?

No, it 'just' hooks the context and root activity to this instance.

Within the activity, you see we create a normal GLWindow and set it's
Android View to become this activities View.

<http://jogamp.org/git/?p=jogl.git;a=blob;f=src/newt/classes/jogamp/newt/driver/android/NewtBaseActivity.java;h=dc14ca3479228dfdf0e7475c4de8b16efc9cab18;hb=HEAD#l65>


>
> I guess this defeats the purpose of your Android version of JOGL, but I will
> ask nonetheless: is it possible to just to use the GL bindings offered by
> JOGL without switching to its NEWT windowing mechanism?

Well, we need to have an implementation of NativeSurface to create a GLDrawable.
Currently we have AndroidWindow implementing it:
  <http://jogamp.org/git/?p=jogl.git;a=blob;f=src/newt/classes/jogamp/newt/driver/android/AndroidWindow.java;h=e747b9ea7dba11bc428778546c250df040eeca48;hb=HEAD>

It basically holds an Android View, which will be used to bind against the Android Window/Context,
and it's being used to create the required EGL and native Android Surface 'binding'.

You may can use this AndroidWindow directly w/o 'bothering' w/ NEWT - yes.
If you need a better abstraction for generalization, we can do that [together].

And as you pointed our right .. currently NEWT is sort of our first use case,
but this shall not prohibit us from adding other scenarios.

Bottom line, for JOGL itself we 'just' need the NativeSurface.

>
> The JogAmp APKs would need to be installed by the end user separately from
> the market (although just once), right?

Yes.
Very good question.

The Android EGL/ES* libraries are organized as follows:

- [1] Android EGL/ES* native library wrapper
  - [2] Vendor specific EGL/ES* native library

[1]'s purpose seems to be to act on certain events and also to
map the 'proper' native values to the vendor ones, e.g. the native surface handle.

I tried to utilize [2] directly w/o any luck.
[We achieve the binding to [1] only by a global 'dlsym' lookup.]

Having said that .. if the specific logic is implemented in [1]
and not in their GL* wrapper itself, I guess will behave the same.
This is at least true for SwapBuffer operations .. where we cannot
control the swap interval for example (really sad ..).

Hope this helps a bit.

And you are more than welcome to clarify the JOGL/NEWT/Android binding,
it always need a few more use cases and people who look at things
to have a great API!

~Sven