Required JOGL Jars to run Java 3D 1.6

Hi,

Reading the deployment information about JOGL, it seems that it's not mandatory to provide the whole jogl-all.jar file to run a JOGL program. Does anyone know here which jar subparts are required to run Java 3D 1.6 to avoid end users to download the big jogl-all.jar file?

Thanks

Hi

There are so much atomic JARs that are required for Java3D (except those for mobile) that I don't advise you to use them. You'll be able to use jogl-all-noawt.jar when Java3D switches to NEWT but this JAR is almost as big as jogl-all.jar

From the current 2.0-rc11 'jogl-all.jar' following packages and classes seem removable. I tested it on my own JOGL 2 pipeline which doesn't depend on GLU. This results in a jar-file of 1,141 KB size.

- com.jogamp.graph
- com.jogamp.newt
- com.jogamp.opengl.swt
- com.jogamp.opengl.util, all without GLBuffers.class
- javax.media.opengl.Debug<profile>.class
- javax.media.opengl.Trace<profile>.class
(- javax.media.opengl.glu)
- jogamp.graph
- jogamp.newt
(- jogamp.opengl.glu)
- jogl.util.data.av

I suggest to avoid the dependence on GLU in JoglPipeline.getPropertiesFromCurrentContext(JoglContext ctx) : GL gl = GLU.getCurrentGL();

Alternatively, the current GL instance could be retrieved from 'ctx' (ctx.getGLContext().getGL().getGL2()) or (better ?) could be provided as a second argument.

August

Thanks August.
It would be really great if jogl-all.jar could be reduced to 1.1 MB from 4.9 MB when run with Java 3D!
Is there an Ant task in JOGL able to build such a Jar automatically, or would it be possible to add it either in JOGL or in Java 3D 1.6?

On 11/27/2012 12:27 PM, Manu [via jogamp] wrote:
> Thanks August.
> It would be really great if jogl-all.jar could be reduced to 1.1 MB from 4.9
> MB when run with Java 3D!
> Is there an Ant task in JOGL able to build such a Jar automatically, or would
> it be possible to add it either in JOGL or in Java 3D 1.6?

Well, the current partitioning of JOGL jar files (*all* and *atomic*)
is based on our current experience and use-cases.

If we can agree to a new jogl non-atomic JAR file combination like
  jogl-all-mobile.jar, jogl-all-mobile.jar or jogl-all-noawt.jar

we surely can provide such, e.g.
  jogl-basic, jogl-basic-noawt, ..


See the 'Footprint Stats' below for different JAR and Pack200 combinations.

Note that there are a few performance criteria:

  [C1] Bandwidth
    [C1.a] Pack200
    [C1.b] Lower number of files

  [C2] Caching and unpacking JARs
    [C2.a] More JAR files take more time to decompress
    [C2.b] Bigger JAR files may take more time to decompress

  [C3] - Memory footprint
    [C3.a] Correlation jar file size and memory footprint is _not_ 1:1,
           since jar files are index (probably mmap'ed) and classes
           loaded and compiled (hotspot) if referenced only.
    [C2.b] Assuming desktop machine don't care +/- 2MB/4MB

As a rule of thumb we have figured that it is best to:

  - Use less files (JAR, pack200, ..) even if the
    total of all-files might be 1-2MB greater than the total of atomic files,
    whether it be pack200 or JAR.

  - At least on desktop machines where advanced file IO and mmap is available
    the JAR file size (~ 2x of pack200) is _not_ in correlation w/ memory footprint.
    And the loading of classes from a 'bigger' JAR file won't impact performance
    to much.

  - Bandwidth limitation (local I/O file seek included) always as a higher impact
    than mmap utilization.

Ofc, on embedded devices we shall be more careful due to RAM and storage limitations,
hence the more limited 'android' and 'mobile' deployed size.

Hope this helps a bit to understand the current state of the art.

Ofc - please continue discussing the deployment size and reasoning here,
so we can make things better (iff there is a good reason to it).

Mind that the more combinations of deployment sets are provided,
the less chance of caching it properly (applet, application ..)
and the higher the user confusion maybe (and hence the more question posted here) :)

~Sven

+++

Previous Footprint Stats:
  <http://jogamp.org/git/?p=jogl.git;a=commit;h=7278244e321dd1d533223e9b6d668a6acd82bc76>

+++

(As attached - dunno how nabble forum will format them)

Footprint Stats:
   
      This demonstrates small footprint of a minimum configuration,
      all numbers in kilobytes (du -ksc).
      NOTE the min size of ~ 1MB!
   
JOGL Deployment Payload for jar

JOGL ALL (JAR)
  244 kB  gluegen-rt.jar
 5208 kB  jogl-all.jar
    4 kB  libgluegen-rt.so.gz
    4 kB  libnativewindow_awt.so.gz
   12 kB  libnativewindow_x11.so.gz
  100 kB  libjogl_desktop.so.gz
   20 kB  libnewt.so.gz
 5592 kB  total

JOGL ALL (Pack200)
   68 kB  gluegen-rt.pack.gz
 2892 kB  jogl-all.pack.gz
    4 kB  libgluegen-rt.so.gz
    4 kB  libnativewindow_awt.so.gz
   12 kB  libnativewindow_x11.so.gz
  100 kB  libjogl_desktop.so.gz
   20 kB  libnewt.so.gz
 3100 kB  total

++

JOGL ALL no AWT (JAR)
  244 kB  gluegen-rt.jar
 4940 kB  jogl-all-noawt.jar
    4 kB  libgluegen-rt.so.gz
   12 kB  libnativewindow_x11.so.gz
  100 kB  libjogl_desktop.so.gz
   20 kB  libnewt.so.gz
 5320 kB  total

JOGL ALL no AWT (Pack200)
   68 kB  gluegen-rt.pack.gz
 2836 kB  jogl-all-noawt.pack.gz
    4 kB  libgluegen-rt.so.gz
   12 kB  libnativewindow_x11.so.gz
  100 kB  libjogl_desktop.so.gz
   20 kB  libnewt.so.gz
 3040 kB  total

++

JOGL Min X11 Min egl es1 es2 (JAR)
  244 kB  gluegen-rt.jar
  320 kB  atomic/jogl-core.jar
  152 kB  atomic/jogl-glmobile.jar
  292 kB  atomic/jogl-util.jar
   76 kB  atomic/nativewindow-core.jar
  120 kB  atomic/newt-core.jar
   28 kB  atomic/nativewindow-os-x11.jar
   28 kB  atomic/newt-driver-x11.jar
    4 kB  libgluegen-rt.so.gz
   48 kB  libjogl_mobile.so.gz
   12 kB  libnativewindow_x11.so.gz
   20 kB  libnewt.so.gz
 1344 kB  total

JOGL Min X11 Min egl es1 es2 (Pack200)
   68 kB  gluegen-rt.pack.gz
  124 kB  atomic/jogl-core.pack.gz
   56 kB  atomic/jogl-glmobile.pack.gz
  104 kB  atomic/jogl-util.pack.gz
   24 kB  atomic/nativewindow-core.pack.gz
   44 kB  atomic/newt-core.pack.gz
   12 kB  atomic/nativewindow-os-x11.pack.gz
    8 kB  atomic/newt-driver-x11.pack.gz
    4 kB  libgluegen-rt.so.gz
   48 kB  libjogl_mobile.so.gz
   12 kB  libnativewindow_x11.so.gz
   20 kB  libnewt.so.gz
  524 kB  total

++

JOGL Android - mobile egl es1 es2 (JAR)
  248 kB  gluegen-rt-android.jar
 3056 kB  jogl-all-android.jar
    4 kB  libgluegen-rt.so.gz
   48 kB  libjogl_mobile.so.gz
 3356 kB  total

JOGL Android - mobile egl es1 es2 (Pack200)
   68 kB  gluegen-rt-android.pack.gz
 1980 kB  jogl-all-android.pack.gz
    4 kB  libgluegen-rt.so.gz
   48 kB  libjogl_mobile.so.gz
 2100 kB  total

++

JOGL Min Android/Mobile Min egl es1 es2 (JAR)
  248 kB  gluegen-rt-android.jar
  320 kB  atomic/jogl-core.jar
  152 kB  atomic/jogl-glmobile.jar
    8 kB  atomic/jogl-os-android.jar
  292 kB  atomic/jogl-util.jar
   76 kB  atomic/nativewindow-core.jar
  120 kB  atomic/newt-core.jar
   28 kB  atomic/newt-driver-android.jar
    4 kB  libgluegen-rt.so.gz
   48 kB  libjogl_mobile.so.gz
 1296 kB  total

JOGL Min Android/Mobile Min egl es1 es2 (Pack200)
   68 kB  gluegen-rt-android.pack.gz
  124 kB  atomic/jogl-core.pack.gz
   56 kB  atomic/jogl-glmobile.pack.gz
    4 kB  atomic/jogl-os-android.pack.gz
  104 kB  atomic/jogl-util.pack.gz
   24 kB  atomic/nativewindow-core.pack.gz
   44 kB  atomic/newt-core.pack.gz
   12 kB  atomic/newt-driver-android.pack.gz
    4 kB  libgluegen-rt.so.gz
   48 kB  libjogl_mobile.so.gz
  488 kB  total


+++

--
health & wealth
mailto:[hidden email] ; http://jausoft.com
land : +49 (471) 4707742 ; fax : +49 (471) 4707741
Timezone CET: PST+9, EST+6, UTC+1

August,

When you talk about your jogl2 pipeline, do you mean an alternate backend for Java3d, or for your own project?

If you have any local patches for Java3d laying around, I'd love to pull them in.

Just curious,

Harvey

Harvey,

as I told you earlier this year my future Java 3D fork (JUniversal3D) will primarily run on native pipelines (ogl, d3d), but I didn't give up the JOGL pipeline. So I started implementing JOGL 2 for JU3D as well.

At the same time I tried to develop an offscreen rendered canvas for integrating Java 3D 1.5.2 into JavaFX 2. As Pbuffer has to be replaced with OpenGL's framebuffer (FBO) inclusive double buffering and MSAA, massive changes were necessary in the native and JOGL code. So, I decided to start another almost fully backwards compatible Java 3D fork called J3D 1.6 on the native pipelines as well as on the JOGL 2 pipeline.

For the JoglPipeline class implementation I try to follow the AWT GLCanvas design, which is similar to yours. Due to the Mac OS X/Java 7 trouble I'm currently splitting the Java 3D core into one for the native pipelines and into another for the JOGL pipeline which will include a Canvas3D class that implements the OffscreenLayerOption interface as AWT GLCanvas does. I will make the JOGL core available here for testing because I don't have access to the Mac platform. All sources wil be published according to Java 3D's GPLv2 with "Classpath" exception license.

SweetHome3D runs fine with J3D 1.6.0 on Windows (JOGL, ogl, d3d) in onscreen and offscreen mode. But JOGL's FBO is still challenging.

August

InteractiveMesh wrote

as I told you earlier this year my future Java 3D fork (JUniversal3D) will primarily run on native pipelines (ogl, d3d)

These pipelines are a nightmare to maintain.

InteractiveMesh wrote

At the same time I tried to develop an offscreen rendered canvas for integrating Java 3D 1.5.2 into JavaFX 2. As Pbuffer has to be replaced with OpenGL's framebuffer (FBO) inclusive double buffering and MSAA, massive changes were necessary in the native and JOGL code. So, I decided to start another almost fully backwards compatible Java 3D fork called J3D 1.6 on the native pipelines as well as on the JOGL 2 pipeline.

For the JoglPipeline class implementation I try to follow the AWT GLCanvas design, which is similar to yours. Due to the Mac OS X/Java 7 trouble I'm currently splitting the Java 3D core into one for the native pipelines and into another for the JOGL pipeline which will include a Canvas3D class that implements the OffscreenLayerOption interface as AWT GLCanvas does. I will make the JOGL core available here for testing because I don't have access to the Mac platform. All sources wil be published according to Java 3D's GPLv2 with "Classpath" exception license.

SweetHome3D runs fine with J3D 1.6.0 on Windows (JOGL, ogl, d3d) in onscreen and offscreen mode. But JOGL's FBO is still challenging.

JOGL/JavaFX interoperability is already possible by porting the mockup based on our competitor and using FBO or by porting jogl-prism to JOGL 2.0 when JavaFX 2 is open sourced in February.

I'm clearly against the creation of another non atomic JAR for JOGL, it would just add some more confusions and some newbies will complain about ClassNotFoundException if Java3D evolves. Why not just using the atomic JARs? We shouldn't create a new non atomic JAR for each scenegraph. 3 MB is not that big especially in applications using hundreds of MB of data.

August,

I'm curious what your goals are then for JUniversal3D, is it intended to be API compatible with Java3d?

I'd really like to explore the option of collaborating on a common baseline if at all possible, there's just
so little manpower available that it seems a shame to split it across multiple projects.  But maybe that's
not compatible with what your interests are...care to share?

Harvey

hharrison wrote

August,

I'm curious what your goals are then for JUniversal3D, is it intended to be API compatible with Java3d?

I'd really like to explore the option of collaborating on a common baseline if at all possible, there's just
so little manpower available that it seems a shame to split it across multiple projects.  But maybe that's
not compatible with what your interests are...care to share?

Harvey

I agree with Harvey, your help is welcome. The backend based on JOGL 2.0 lacks a very few features compared to the native ones and it will be fixed. In my humble opinion, it would be more efficient to work together on a common version of Java3D and you could still work on your own framework based on it, you would benefit of all future improvements in both Java3D and JOGL 2.0 including OpenGL/JavaFX interoperability.

Harvey,

as a consequence of the goals described in the initial post http://www.java.net/node/686625 there is no way to keep JUniversal3D's API compatible with Java 3D. But the intention is to stay as close as possible.

To explore options of collaborating on a Java 3D compatible API we should wait until J3D 1.6.0 is available. Yes, you´re right, our interests differ. For me the natively programmed pipeline Windows&Linux/OpenGL should be the guideline for features and capabilities of the API.

August

Is your JUniversal3D code available anywhere?

Some commits from my side you may or may not be interested in:

Locking fixes (that were hittable in practice):
https://github.com/hharrison/java3d-core/commit/3bd82be0371e40390abc5509cb2a7d6e3a055a12
https://github.com/hharrison/java3d-core/commit/35f31b94b83b2aadd76792827f7d687969b7bbde

Locking fixes (not actually triggered, likely only accessed form one thread)
https://github.com/hharrison/java3d-core/commit/414c861df0f72ce5c90cf3106798c103fcc07a76

Type fix
https://github.com/hharrison/java3d-core/commit/f24a01217f39df3b02a01444ac1a720994f090c8

Otherwise, there's a series of patches the cuts the memory use of the Bounds objects in half and
makes them quite a bit more efficient for the common case and a pile of type annotations on
collections.

I'd be interested in any fixes you've made in the native OpenGL backend, or if you happened to notice any
bugs in the jogl backend that weren't ported properly from the native backend.

Thanks

InteractiveMesh, I have just read your plans. I have to remind you that the OpenGL native renderer was not working under Mac, such a port would be non trivial to create and particularly painful to maintain (just look at the difficulties we have to keep Mac support in JogAmp).

Secondly, scenegraphs written in Java rarely use their own bindings, they only do so when there is a real problem with existing ones or when they have no other solution. For example, JMonkeyEngine 3 uses its own binding for Bullet but uses both JogAmp and our main competitor for OpenGL and OpenAL.

Thirdly, reinvent the wheel only when yours is better. GL4Java, Jungle and JogAmp have required tons of efforts, don't underestimate this task.

Fourthly, most scenegraphs prefer being modular, separating the concerns ans reusing existing APIs. Creating a scenegraph is already a real challenge even though you don't start from scratch.

In my humble opinion, developers feel better with less but better maintained scenegraphs rather than tons of semi-broken similar ones. I try to avoid effort duplication, that's why I suggested you to build your framework above Java3D instead of maintaining your own fork.