Minimal JOGL

OpenGL Development JOGL Development
#1

Has anyone tried to find out the smallest
possible size for using JOGL?

jogl.jar is currently 837KB. Can this use Pack200
via Webstart?

jogl-natives-win32.jar is currently 56KB.
If I remove jogl_cg.dll which I don’t need
then it is 40KB. I doubt this can go much
smaller but does anyone has any idea?

My aim is to reduce the first-run wait that
the user has to go through. If the user is on
a 56Kbps modem, then that’s about a
2-minute wait. A 512Kbps ADSL line will
need about 25-seconds.

Using tricks like parsing the class files
and rip out methods that are not used is
not a good idea because you never know
when you will need them again when your
app is updated, without having to re-download
JOGL.

Any suggestions?

.rex

#2

jogl.jar compresses very well with Pack200 from what I’ve read from users on these forums. We haven’t investigated this yet for the standard distribution because Pack200 is only compatible with JDK 5 and above and we need to stay backward compatible with 1.4.2.

#3

JOGL does indeed compress well with JDK 1.5

Since the pack200 is named differently then the jar file the two could co-exist nicely with 1.5+ clients downloading the pack200 and 1.4 using the jar, at least according to
http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/faq.html#217

#4

Can’t you design your JNLP file to serve a pack200 file for Java 5 and a normal one for earlier versions?

I’m pretty sure this is easy to do in a JNLP file. You can have multiple elements. See section 4.6 of the JNLP 1.0.1 spec.

#5

Actually I have to think about that more… You could probably have the situation that the Java Web Start launcher that is running is the 1.4 version even though Java 5 is installed…

#6

All of the documentation I’ve seen on deploying Pack200 via Java Web Start involves tricky server-side stuff. I’ll have to look into whether the server where the JOGL binaries are hosted supports any of the server-side hacks needed. Of course if it were possible to express things in a portable way in the JNLP file that would be a good solution.

#7

The serverside stuff is not so hard. In fact it’s overcomplicated. You can simply return the pack200.gzipped jars to 1.5 clients by specifying them that way in the jnlp file, and return ordinary jars to 1.4 clients.

Cas :slight_smile:

#8

I did some investigating and got the
following results.

  1. unzip jogl.jar and rezip it without the manifest directory (otherwise it causes some exceptions with pack200)
  2. run “pack200 --repack jogl.jar”
  3. run “pack200 --modification-time=latest --deflate-hint=“false” --strip-debug jogl.pack.gz jogl.jar”

jogl.jar: 837KB -> 199KB !

I think this calls for some serious look
into the possibility of having jogl.jnlp
serve the packed version for Java 1.5+.
Ken? ;D

.rex

#9

:o

drool … must investigate … drool

#10

I did get much smaller sizes while keeping things compatible with java 1.4.2, for example:

jogl jar = 102K + 48K for the win-32 native libs
more numbers http://www.chronotext.org/Isaiah/lib/

It was a long process to achieve, but here it goes (off-hand):

  1. make separated jars for each platform (e.g. removing ANY macos or linux specific code from the windows version…)
  2. get rid of what’s not absolutely required (e.g. stripping jogl_cg.dll)
  3. use an obfuscator like proguard to shrink everything from your project AND from jogl.jar TOGETHER

Point 3) is the most important one: it implies in theory to create specific jogl libs for each of your different projects (instead of having one big jogl.jar that serves for everything…), so it’s not the perfect solution…

All in all, you can check this jogl project and appreciate the very fast downloading times!

ariel
http://ariel.chronotext.org

#11

You only need to specify usual jars and thats it (on the jnlp side). The jws client sends some request and if the accepted encoding is set to “pack200-gzip”, you return the p200/gzipped jar together with the right content encoding. And 1.4 clients dont send any accepted encoding… therefore you send the usual jar in that case.

Thats basically how it works.

I’ve roughly explained how to do it with php and .htaccess here:
http://www.java-gaming.org/forums/index.php?topic=6195.msg96070#msg96070

#12

Is there any way to implement this with no server-side support? For example, you can specify multiple j2se elements in certain contexts, and I would like to be able to just indicate that for 1.4, transfer jogl.jar, and for 1.5+, transfer jogl.jar.pack200.gz or similar.

#13

AFAICT… no.

The content encoding bit does the magic (it tells the jws client to unpack it on the fly - similar to gzip compression for html files). So, you need at least those content encoding parts of the htaccess.

Well, on the bright side… some webspace with this kind of features* only costs a fiver per month.

[* 1. htaccess 2. php 3. mod_rewrite (optionally)]