We produced a presentation video showcasing JogAmp’s objectives:

Jogl/JogAmp on the Web, Desktop and Mobile 2012

RC6 is now underway, I still have to add some supplied patches and walk through the buglist though.
However, this time I have to complete this task until tomorrow regardless whether I could complete the bug walk or not.

Cheers, Sven

Even though GlueGen and JOGL in general support EGL and ES1/ES2 since 2008 incl. the GL profile selection,
we figured we need better support for multiple GL implementations on one platform, Mesa3D software and the hardware EGL/ES ones.
Without tweaking your default configuration, JOGL chooses the right implementation for the desired profile,
e.g. hardware accelerate GLES2 for the desired common GL2ES2 profile on your mobile device, even though Mesa is installed.

Besides tiny big fixes and workarounds the biggest amount of work was to attach the Linux ARMv7 job to Jenkins.
We use a cross-compile and cross-test environment, where the build host cross-compiles and makes the Pandaboard ES
fetch the artifacts via rsync and execute the tests. Later the build host pulls the results and forwards them to the Jenkins master.

All JogAmp modules are now build for Linux-Armv7,
a test release is made available here.
You may like to try the test Applets.
Note: This week RC6 will be released under the usual location and the above test URL will cease to exist.

I dared to test browser support via OpenJDK and the IcedTea Plugin,
and for some reason .. it just works

Please feel welcome to join the discussion.

JOGL on Linux-ARMv7-Omap4

Besides many important bug fixes this release supports
Mac OS X 10.6.4 and 10.7.

The Applet browser plugin is also enhanced and validated
on all platforms for FF, Chrome, Safari and IE where supported.

http://jogamp.org/deployment/jogamp-current/jogl-test-applets.html

+++

We have to thank each other for our ongoing support,
bug reports, inspiration and pushing for results.

Thank you.

+++

The following aliasing of URL location has been made,
ie. all are aligned to v2.0-rc4 for now.

http://jogamp.org/deployment/

• v2.0-rc4 -> archive/rc/v2.0-rc4
• jogamp-current -> v2.0-rc4
• jogamp-next -> v2.0-rc4
• webstart -> v2.0-rc4
• webstart-next -> v2.0-rc4

Developer downloads at:
http://jogamp.org/deployment/v2.0-rc4/archive/

Git repositories have been tagged w/ v2.0-rc4.

+++

Planned for RC5 so far:

RC5:

• Maven2 integration (I know .. a bit late it is already)
• Mobile/Android autobuilds / release
• More bugfixes
• Update the graph package

+++

Please join the discussion in our forum.

You may like to comment on this release here.

Cheers, Sven

Here are the latest good and failed test charts for all platforms:

Test Stats 20111013 All	Test Stats 20111013 All - Errors Only
Test Stats 20111013 All - Failure Chart

And finally the progress on OS X with all tests included:

Test OS X 20111013 Overview
Test OS X 20111013 Count	Test OS X 20111013 Runtime

Besides adding running all unit tests to OSX, we also made sure that it’s performance is now equal to the other platforms, ie. around 4 minutes runtime for all tests.

• Our Jenkins (Chuck) test result page for the above numbers
• JogAmp
• How to download and install.

But be aware that these features will be promoted to the next release RC4,
so you would need to wait or use the autobuilds, see Downloading the latest automatic build.

What should work for OS X by now:

• NEWT Top-Level Windowing
• NEWT Child Window w/ NEWT Parent
• NEWT Child Window w/ AWT Parent
• JOGL incl. shared context
• NEWT works w/ AWT enabled JVM out of the box
• Method to execute a Runnable on the MainThread
• The new native Jar loading facility (Application, Applet, Webstart)

The window positioning code was a torture, since the AWT components are not top-level on OS X. Hence we have to calculation the proper screen size position in bottom-left coordination space, even when resizing the window.
Maybe there are still some glitches in case of a NEWT child within an AWT floating Container, but most cases work fine.

Shared or offscreen context destruction was another issue.
We have to run this task on the MainThread, otherwise we experienced a ~10s freeze.

Btw our MainThread semantics have been simplified a lot.
On OS X, it just launches the user main class in a new thread while continuing as the NSApp MainThread.
In short, it is no more required when using an AWT enabled JVM, since it already launches as the NSApp MainThread.

After a few more cleanups, I will prepare the next release and test our new native Jar loading mechanism
and Applets in general.

• JogAmp
• How to download and install.

But be aware that these features will be promoted to the next release RC4,
so you would need to wait or use the autobuilds, see Downloading the latest automatic build.

Note on the side: Motivation for the OS X port was not my liking of the platform, which I don’t, but to just complete our platform independent solution. Hence having NEWT working well on OS X is mandatory here.

• Visibility
  set pointer visible or invisible
• Confined
  confine pointer to window, or not
• Warp
  set mouse position within the window

This is NEWT’s minimal API addition in this regard.

The InputEvent’s modifiers expose the above states confined and invisible
which can be easily queried and reacted upon in the event listener, as shown in GearsES2.

This allows you to have a game-like mouse navigation, where you control the direction w/o pressing the mouse button (which you may need for something else), not seeing the mouse pointer and last but not least,
not leaving the game window.

Tested w/ TestGearsES2NEWT, using
GearsES2.

This is currently impl. for X11 and Windows and I am currently adding these to our OSX port.
Since the default operation for these features are NOP and touchscreen don’t require any of those, there is no work to do on Android in this regard.

• JogAmp
• How to download and install.

But be aware that these features will be promoted to the next release RC4,
so you would need to wait or use the autobuilds, see Downloading the latest automatic build.

Just go to this test deployment folder:
http://jogamp.org/deployment/test/android/201110080141utc/

Download all the APKs:

1. gluegen-rt.apk
2. jogl.all-android.apk
3. jogl.test.apk
4. jogl.android-launcher.apk

and install them via the ADB:

   adb install gluegen-rt.apk
   adb install jogl.all-android.apk
   adb install jogl.test.apk
   adb install jogl.android-launcher.apk

You can uninstall them as follows:

adb uninstall com.jogamp.common
adb uninstall javax.media.opengl
adb uninstall com.jogamp.opengl.test
adb uninstall com.jogamp.android.launcher

The APKs are currently just signed with a temporary key and debug is enabled.

Uninstalling them manually is required when you like to try to test a new version,
which will appear in the same parent folder under a different timestamp soon.

Please visit our forum at http://forum.jogamp.org/,
actual thread for this test release is
http://forum.jogamp.org/Android-Test-APKs-201110080141utc-td3404613.html,
and leave your comments there if you like, thank you.

The API in regards to Android is under review and will change
to make the experience more comfortable.

However, we already achieved to run a Java module on desktop as an application or applet
and on Android / Mobile w/o any change.
This is the main goal of porting JOGL on Android, no need for native code or rewriting your application.

Cheers, Sven

GraphiCon 2011 Book

Resolution Independent NURBS Curves Rendering using Programmable Graphics Pipeline

about the math of JOGL’s new graph package …

Resolution Independent GPU Accelerated Curve & Font Rendering

.. we finally made good progress in completing the Android port including graph.

JOGL/JogAmp @ Red Square / Moscow (edited)

0:00 – 1:20 : Part 1 – Gears ES 2.0 @ Red Square @ Day
1:25 – 2:50 : Part 2 – All Demos @ Red Square @ Night
2:50 – 3:45 : Part 3 – Graph UI on Tablet & Phone

1. Asus Transformer, Android 3.2, NV Tegra2
2. Samsung Galaxy Tab 10.1, Android 3.1, NV Tegra2
3. Samsung Galaxy S2, Android 2.3, ARM Mali 400 MP
4. Samsung Galaxy S1, Android 2.3, Omap 34xx

We have expected glitches in the OpenGL drivers and/or Android environment
and even found bugs which does not exist on a similar device, ie device 1 and 2.

Device 3 works absolutely flawless, kudos to the ARM developer
of the MALI silicon and it’s drivers! No workaround is necessary and our demos worked
straight out of the box, even w/ multisampling enabled.

Device 4 shows flickering on all demos, where the FPS value
is always just around 18-23, hence below V-Sync.
We actually have no clue why, since device 3 works perfect. Since both devices are mostly equal
but it’s GPU .. we must assume it’s about the Omap3 driver.

The Tegra2 devices gave us quite a headache

Device 1 and 2 (hence Tegra2) exposes the following bugs:

• discard in fragment shader freezes the GLSL compiler
• mixing sampler2D w/ a non texture code path let’s GLSL compiler result in error
  P1202 Texture's gl states do not match with shader's

Device 2 also exposes an interesting bug not available on the other Tegra2 device,
which rendered all our demos invisible, ie. resulting in a blank screen, where only the clear color was shown.
Hunting down this one took also quite a while, but after stumbling over NV’s PerfHud ES and some hints about how to enable it on consumer devices the culprit was found.
The GLState Viewer exposed that our uniform mat4 mgl_PMVMatrix[2]; wasn’t set via glUniformMatrix4fv(..), probably a bug within the OpenGL ES 2.0 driver code.
Actually device 1 and 2′s libGLESv2_tegra.so differ where the other EGL/GL driver files are the same. However, replacing it did not do the trick.
Replacing the mat4 array with a simple uniform mat4 mgl_PMVMatrix; did the trick, ofc we need a better workaround for this case.

Update: The mat4 array bug turns out to be Android 3.0 Dalvik Issue 16434. A simple workaround for our PMVMatrix is submitted.

Further more Tegra2 doesn’t support the old fashioned MSAA, but their own new extension
EGL_NV_coverage_sample, to which we will have to revert to in our multisample GLCapabilties.

jogamp-next points now to the signed beta build gluegen_410-joal_213-jogl_489-jocl_424-signed.

See how it (NApplet) works online on the new JOGL Applet Test page.

Without the need for using

• our Applet-Launcher
• the JNLP extension
• setting up the native library folder for applications

we automatically

• verify all it’s certificates (for non applications)
• cache the JAR files native libraries
• use the cached native libraries

As you can see in the documented html pages:

• JOGL Version NApplet
• NEWT Gears NApplet

.. this simplifies the tag writing and removes the need to write your JNLP file.

The native JAR download mechanism still benefits from the applet’s
network cache mechanism, hence downloads the JAR only

• if it doesn’t exist, or
• if the server version is updated

Of course, this causes a network connection but surely not a big deal
and more correct. Users can still use the JNLP mechanism of course
using the JNLP tag:

  <update check="background" policy="always"/>

Applications don’t need to worry about the system dependent way
of dropping and publish the native lib folder anymore.
Applications also load the native JAR file and use their native libs,
just deploy all JARs in the same folder – done.

Git commits in this regard:
– GlueGen from f357a00e511f0049865392adecc4d042663da6e6 upto 609e649443f900116039cda7a1bc7c9359b0242f

– JOGL from ac358bd66878e63a370377d4c7f625ec5b1b9e31 upto 424a5ecbd7575eb39343638696c19cd617577912

This feature will be enabled in general for rc4 soon.

Please reply w/ your concerns and ideas etc,
so we can make this one work fine and secure for all.

Cheers, Sven