Processing 1.0 - Processing Discourse - Success in creating OpenGL Processing applet

cchoge

Success in creating OpenGL Processing applet
Nov 13^th, 2005, 10:17pm

Hi,

I've created a Processing applet that uses the OpenGL renderer and can be loaded over the web. I used a JOGL loader written by Lilian Chamontin and located at http://www.vlsolutions.com/free/jogltest/.

The first step is to set up a certificate to sign your jar files with. This is done with the command

keytool -genkey

Next, download the loader from Lilian's page and patch it to be compatible with the native JOGL libraries provided by Processing. Here is the patch (it should be obvious where to apply it):

/** native libraries location */
private static final String [] nativeLibsJarNames = {
"jogl-natives.jar",
"jogl-natives.jar",
"jogl-natives.jar",
};

I also deleted the package directive at the top of the class.

Generate your OpenGL applet with Processing, and place the patched loader class in that directory. Now, execute the following script (making the appropriate name change for the Processing generated jar)

jarsigner ProcessingProg.jar mykey
jar -cf jogl-natives.jar *.dll lib*
jarsigner jogl-natives.jar mykey
javac -classpath ProcessingProg.jar JOGLAppletLauncher.java
jar -cf Launcher.jar *.class ProcessingProg.jar jogl-natives.jar
jarsigner Launcher.jar mykey

Finally, modify your index.html file applet section to read (set the width and height appropritately, as well as the Processing program to load):

<applet code="JOGLAppletLauncher"
width=200
height=200
codebase="."
archive="Launcher.jar,ProcessingProg.jar">
<param name="subapplet.classname" VALUE="ProcessingProg">
</applet>

That should do it.

I've verified this with OS X. I have an applet up on a private server, so if any Linux or Windows users want to verify that this actually works send me a message and I'll forward the URL to you.

-Chris

Ricard Full Member Offline Posts: 193	Re: Success in creating OpenGL Processing applet Reply #1 - Nov 14^th, 2005, 12:06pm I will try it. I'm a linux user.

JohnG

Re: Success in creating OpenGL Processing applet
Reply #2 - Nov 14^th, 2005, 12:08pm

I've followed your instructions, and managed to get a working openGL applet online.

I did find that I had to change one part though, instead of:
Code:

archive="Launcher.jar,ProcessingProg.jar"

I had to use;
Code:

archive="Launcher.jar,ProcessingProg.jar,jogl-natives.jar"

As well as having all 3 jar files in the same directory on my webserver. Would it not be possible to keep the 3 jar files small and seperate, instead of including both the applet and natives jar into the Launcher, since they seem to need to be there seperately anyway?

If anyone wants to test this, and is willing to trust an applet I've signed (and therefore could do many evil things, but I promise that I have not written any code that could do evil) the URL is:
http://www.hardcorepawn.com/openglapplet/

I've also noticed, that this only seems to work the first time you load the page. If I go to another page, then return to the page with the OpenGL apple ton I get the following error in the Java console:
Code:

java.io.FileNotFoundException: C:\Documents and Settings\jgilbert\.jogl_ext\www_hardcorepawn_com_openglapplet_\jogl.dll (The process cannot access the file because it is being used by another process)

Ricard Full Member Offline Posts: 193	Re: Success in creating OpenGL Processing applet Reply #3 - Nov 14^th, 2005, 12:59pm Hi JohnG The applet worked fine for me. And I didn't have the problem you were talking about when I go to another page and then go back. OPENGL on applets is great!! thanks

Ricard

Re: Success in creating OpenGL Processing applet
Reply #4 - Nov 14^th, 2005, 1:03pm

I'm wondering if it would be possible that the certificate was always the same (e.g. by the creators of JOGL).

Like that we only have to trust them and not every author of each applet.
They could provide along with their JOGL drivers, an all prepared loader. And only the loader is trusted not the rest of the applet.

It's maybe nonsense what I'm saying.

d3

Re: Success in creating OpenGL Processing applet
Reply #5 - Nov 14^th, 2005, 1:48pm

lilian did some great research here.
i d like to motivate the discussion though whether this is the best way to do or not.

the problem with opengl in an applet so far was, that the native libraries (.dll, .jnilib, .so) could not be loaded by the opengl applets. to resolve this issue one could either install jogl into the java virtual machine by hand, choose the 'lilian' approach or another one which is basically outlined by the 'jsyn' plugin installer.

we put together a very basic/buggy implementation of the later approach as a more general application that can install any kind of library including 'jogl'.
the joglextensioninstaller / src installs the jogl version distributed with processing 95. we did this mainly to prove the concept.

i d really like to discuss openly now which approach is the better one, or which one you all feel more comfortable with.

the advantages of the 'lilian' approach is that it can keep several jogl versions and doesn t mess with an existing jogl installation.
the disadvantages are that the process of one applet loading another etc is rather complicated and that jogl is only available on that environment if the 'lilian' applet is used thus a standalone application on the same machine that can run an opengl applet, might not find the jogl libraries.

the advantages of the 'jsyn' approach are that the actual opengl applet doesn t need to be signed as proven in this little example here and that the jogl libraries are installed for a whole virtual machine.
the disadvantage is that there can only exist one version of jogl.

my personal favorite is the 'jsyn' approach. install once and then don t bother again but i d like to hear your opinions.

BTW the reason that a processing applet needs to get signed to run opengl is processing specific not jogl specific, as proven in the example above. this, of course, only works if jogl is installed properly.

cheers.

JohnG

Re: Success in creating OpenGL Processing applet
Reply #6 - Nov 14^th, 2005, 2:23pm

For what I do, expecting people to "install" anything is likely to lose visitors by the bucketload, because they're naturally lazy, and don't like things to be at all complicated. And I like not having to rely on a plugin author to have anice easy to use, and importantly, safe install page somewhere.

With the above system, the end users don't need to do anything other than hit "yes" on the security box, and it all just works. (though getting people lulled into just hitting yes is a bad thing...)

The end user doesn't care about versions of JOGL or the like, and should not have to worry about such things at all IMHO.

d3

Re: Success in creating OpenGL Processing applet
Reply #7 - Nov 14^th, 2005, 2:59pm

hey JohnG

it s interesting that the things you mention exactly outline the mechanics of the flash plugin. there you have to go and install etc. i m not saying that it s the best way, but at least it worked in a few occasions.

actually i think that the experience of installing a plugin depends very much on the way it is presented. the 'lilian' applet is also an installer from a certain perspective. it downloads and stores file on you harddrive.

to me the important question is; do we want a mechanizm that installs a library into the JavaVM so that it becomes accessible at all times but only allows one version or do we hide the versions from the JavaVM but have to rely on a certain applet / mechanism to pick the right on for us?

and again, in terms of user experience these two version don t really differ that much. btw since the sourcecode for installers of this kind should be opensource there is no relying on a 'plugin author'.

cheers
d3

mkn

Re: Success in creating OpenGL Processing applet
Reply #8 - Nov 14^th, 2005, 3:34pm

If a plugin alternative is considered I'd like to suggest that it might be better to coordinate this into a bigger plugin plan. I dont think that this is a bad idea, though I dislike the complicated jSyn plugin concept which is way to user unfriendly and definitely scares audience off. And, the more of these complicated plugins, the worse the name of processing applets, and consequently the less the people who will want to check out your latest and coolest processing stuff.

I mean, how hard would it be to coordinate and maintain a processing plugin project? It could integrate the processing core, standard libraries and user libraries, maybe some widget stuff, openGL, and sound libs as well. If processing applets were to run through a plugin I guess it could be made so that you wouldn't have to have signed applets for accessing non-home URLs. It could do regular checks on updates of installed components and do automatic search for missing libraries that are called to a db on the dot org. All under one nice and user friendly installer and extremly simple plugin GUI. Like the competition. Only cooler.

(Also. Java is a plugin as well. Nothing native about that...)

Ricard

Re: Success in creating OpenGL Processing applet
Reply #9 - Nov 14^th, 2005, 4:20pm

Hi JohnG,

About the:
Quote:

the end users don't need to do anything other than hit "yes" on the security box

I think the clicking "yes" to each and every applet that uses openGL isn't a good idea. Then the user must trust every single people that makes an applet. And the applet could be installing anything. So I think it's not a good longterm solution. If people with not much knowledge get used to clicking 'yes' this could become a big "security hole". And then lowering the popularity of signed applets. Insted if we only have to trust the plugin makers (d3's solution) then the trusting would only have to be done once.

Let me know what you think. Is there a possibility of a intermediate solution. An automatic call to an installer if the jogl libraries aren't found. Making it more user friendly?

cchoge

Re: Success in creating OpenGL Processing applet
Reply #10 - Nov 14^th, 2005, 4:37pm

I like both approaches. I spent several hours over the weekend scouring the web for the jsyn approach. That's when I came across the lilian approach, and spent the better part of yesterday morning figuring it out. My personal preference is to have jogl available as part of the jvm, like Java3D is (after all, Java3D can be built upon OpenGL, so why can't we have JOGL there too). I also like not having to download a relatively large library every time I want to run a JOGL applet.

Having said that, for now I'm happy with the lilian approach. It seems that the JOGL people are pretty happy with it too; lilian's code has been tasked to be incorporated into the official JOGL distribution.

d3 wrote on Nov 14^th, 2005, 1:48pm:

lilian did some great research here.
i d like to motivate the discussion though whether this is the best way to do or not.
<snip>
the advantages of the 'lilian' approach is that it can keep several jogl versions and doesn t mess with an existing jogl installation.
the disadvantages are that the process of one applet loading another etc is rather complicated and that jogl is only available on that environment if the 'lilian' applet is used thus a standalone application on the same machine that can run an opengl applet, might not find the jogl libraries.

the advantages of the 'jsyn' approach are that the actual opengl applet doesn t need to be signed as proven in this little example here and that the jogl libraries are installed for a whole virtual machine.
the disadvantage is that there can only exist one version of jogl.

my personal favorite is the 'jsyn' approach. install once and then don t bother again but i d like to hear your opinions.

BTW the reason that a processing applet needs to get signed to run opengl is processing specific not jogl specific, as proven in the example above. this, of course, only works if jogl is installed properly.

d3

Re: Success in creating OpenGL Processing applet
Reply #11 - Nov 14^th, 2005, 5:04pm

Ricard wrote on Nov 14^th, 2005, 4:20pm:

Hi JohnG,
Let me know what you think. Is there a possibility of a intermediate solution. An automatic call to an installer if the jogl libraries aren't found. Making it more user friendly

the yes-button-clicking is a really interesting point.

actually i too like the way the 'lilian' applet is checking for jogl without the client noticing, though.

and i absolutly like the idea of having a centralized effort like a processing plugin project. processing libraries that have native parts, like jogl, odejava, rxtx or joal, can be installed from there. people are willing to trust these installers because they are maintained/written by those trustworthy processing people.

any comments/ideas on how to advance this effort

it s true the jogl people are happy about the 'lilian' applet. here is the corresponding thread from the jogl forum.

cheers
d3

clilian

Re: Success in creating OpenGL Processing applet
Reply #12 - Nov 17^th, 2005, 11:28am

Hi everyone, I'm the 'lilian' you were talking about in that thread

I just wanted to add something to clarify your discussion about code signing :

If the jogl natives are the only ones you need for your processing applets, then once the JOGLAppletLauncher will be added to jogl.jar, you will not have to re-sign it with your own certificates (just use the jogl default cert from Sun).

That way, there's not need to trust everybody's applets, you just agree once with the trusted certificate that has been used to sign jogl.jar and it's related natives.

Hope it helps.

(now I'm going to have a look at this processing stuff as I wasn't aware of it).

Lilian

Ricard

Re: Success in creating OpenGL Processing applet
Reply #13 - Dec 3^rd, 2005, 11:49pm

Hi there,

I'm trying this method for running OPENGL empowered applets and I'm running into a little problem when trying to load files that are supposed to be in the "data" folder of the sketch.

I think the problem is that when I call the new processing methods sketchPath() and dataPath() are actually looking inside Launcher.jar instead in ProcessingProg.jar. I'm guessing there might be an easy hack to make it work, does anybody know?

Thanks!!