Login  Register

Re: Some issues using NEWT

Posted by Sven Gothel on Mar 22, 2012; 8:46am
URL: https://forum.jogamp.org/Some-issues-using-NEWT-tp3757230p3847868.html

On 03/22/2012 05:38 AM, ac [via jogamp] wrote:
>
>
> Going back to the Android suggestion, I looked briefly at the
> NewtBaseActivity class and some examples like NEWTRedSquareES2Activity.
>
> The initialization code looks very compact thanks to the GLWindow and
> GLCapabilties objects.

Assuming you refer to the latest ..

<http://jogamp.org/git/?p=gluegen.git;a=commit;h=0cfc7847c58b51c9a26b50d905b592d1fc4c8578>

yes, it's seamless using NEWT w/ Android, i.e. target to require no code change
of your Java/JOGL application.

> However, it also seems to me that in order to use
> jogl-android in Processing we'd probably need to do some fair amount of
> rewriting since Processing on Android is currently based on the SDK's
> Activity class plus our own customizations for input, etc, and uses a
> GLSurfaceView to handle the OpenGL surface.
>
> Since we already got this basic stuff working and are accessing GLES2
> through the native Android bindings, I'd like to know what would be the
> added benefits of using the JOGL bindings instead. I can imagine that having
> the same API on both desktop and Android is one,
Yes, sure. Plus soon we will enable unit testing as well etc.
So the big points for JOGL/Android IMHO is:
  - lower costs of cross-platform development and maintenance
    due to reusing the same code path
   
  - quality
    - maturing our common Android binding instead
      of every app on their own

    - benefit from our [cross platform] unit tests

> but we already wrote a
> Processing-GL abstraction layer that encapsulates the platform-specific
> APIs. On the negative side, Android applications would need to be bundled
> with additional files (jogl.all-android.apk, jogl.all-android.jar...? not
> exactly sure wich ones are needed).

As mentioned above [latest GlueGen/JOGL Android changes],

 [User:a1] -- (usr-data) --> [Launcher] -> [User:a2] + using [other packages..]
   
    [User APK]   - The user provided APK
    [JogAmp APK] - JogAmp APKs
   
    [User:a1]    - The initial user activity, which starts the [Launcher].
                   Providing data to [Launcher]: [User:a2], [User APK]
                   Resides in [User APK]
   
    [User:a2]    - The actual downstream 'real' activity, spoiled w/ full fledged ClassLoader
                   having access to all packages as requested, ie. [User APK], ..
                   Resides in [User APK]
   
    [Launcher]   - The launcher activity.
                   Gets called by [User:a1].
                   Creates a new ClassLoader, daisy chainging all requested APKs.
                   Instantiates [User:a2] w/ new ClassLoader.
                   Delegates all calls to [User:a2].
                   Resides in [JogAmp APK].

- you would only need to install the [JogAmp APK]s on the phone

- then you install your [User APK]

- then your 'dummy' [User:a1] activity kicks of your real activity [User:a2]
  while using [Launcher], which daisy chains ClassLoader and allows access to all
  pre installed JogAmp APKs ..


One thing is for sure here .. our Android binding is bleeding edge.
However, it's sort of 1st priority and we will work swiftly to fix bugs
and to enhance it, e.g. based on your requirements etc.

So I really would love to see Processing using JOGL/Android,
which would allow us to mature the binding ASAP.

So I guess the benefits are clear and the 'risks' as well.

Hope this helps a bit.

After RC6, I will try to push a 1st version to the market,
so it can be installed as usual.

Cheers, Sven



signature.asc (910 bytes) Download Attachment