JOGL in applet

OpenGL Development JOGL Development
#1

Hi,

one of the biggest disadvantages of JAVA+3d in web environments
(applets…) is the necessety to let the user authorize the use of the native
libraries (user has to click at least once “ok”). This and the load time
are the main problems with java compared to flash. Although flash’s 3d
capabilities and quality are very poor, people like google prefer using flash
instead of java just for those reasons I believe (have you seen google’s
street level, that could be 100 times nicer using java+jogl!). So are there
any chances that these issues will be resolved/addressed differntly in the future
(java’s strict security policy could be revisited especially for JNI stuff…)?
I’m just afraid tha flash will take over the whole web, which is quite a pain…

What do you think?

Regards,

Toni

#2

As long as Java3D and Jogl are not parts of the regular JRE/Java plugin, this issue will not go away.

#3

Is there any indication this could happen?

#4

We have been considering not presenting the security dialog for Sun-signed binaries, as these are basically implicitly trusted. I have some reservations about this, as it should probably be the user’s choice, but this would simplify deployment (even though in general you should only see the security dialog one time). What do you think?

#5

Sounds like a winner to me. If a user doesn’t trust Sun, they probably shouldn’t be running the JRE in the first place.

#6

Hi,

that could be a solution. It’s not clean&nice but… Yes, I know you have to confirm only
once the dialog box, but that’s enough to scare away users. Users not knowing what a
“certificate” is, just don’t understand what’s going on, they perceive it as something
“negative” and are scared by the site. When they navigate the web, they don’t want to
confirm anything. This pop-up must be eliminated somehow. Considering that there’s
no standard yet for 3d applications on the web, sun is missing a great opportunity
here (they already failed with the JMF, do they learn from errors?). Perhaps including
JOGL into the JRE as suggested by “cylab” could be a good solution. OpenGL is cross
platform and a modern graphics API, you just can do everything you could imagine of in 3d,
in an APPLET !!! And more: we recentrly included the mp4 player from http://mediaframe.org/
into an applet, that stuff just rocks, listen: you can map a video stream as texture onto
arbitrary 3d objects! The page mediaframe.org is pretty much dead, but there are more
recent versions from airlock. They are worting on RTP streaming of mpeg4 files…
Just imagine youtube done with all this stuff. It would be a 100 times better and the world
would be a better place (flash is closed source and steered by “evil” companies like Adobe,
their new video codec o2 is a secret… :slight_smile: So, sun: WAKE UP, take the opportunity,
don’t let us down with flash! Hopefully somwbody hears me…

Regards,

Toni

#7

So can 3rd party libraries get signed by sun ?

#8

I’d like to think we have learned from our past mistakes. We did figure out how to do dynamic downloading of extensions like JOGL in the context of applets, and are continuing to refine the technology. Even though I’m the JOGL project lead, I continue to resist bundling it in to the core JRE, as doing so introduces problems and we need to solve the extension deployment problem more generally (and we are working on this).

That’s very cool. Do you have an online demo of this stuff?

#9

Hi to everyone… i’m very interested in this topic, as i’m really looking forward for Java as the standard for web multimedia.
Good and general design is important, but time is really critical now! The risk is to let Flash to become “the only solution”, and loose the battle for Java as an open and versatile multimedia platform on the web.

If we keep on thinking and thinking for another year , we’ll get a perfectly-designed, open, and useless multimedia platform :-\

#10

Replace “Sun” by “Microsoft” and notice the sudden creepy. I vote strongly against doing this.

#11

[quote=“Ken Russell,post:8,topic:30172”]
Just curious, what’s exactly the reason why you are against putting JOGL in the core?

I imagine that flexibility is one of the reasons? You wouldn’t be able to keep on improving JOGL at he same rate as you are doing now. But what are the other reasons? Because personally I would love the idea that 3D graphics come with “the package”.

Of course if JAMs and the whole OSGi-like system becomes a reality all of this might stop to be relevant.

#12

long time without news about this but we have finish the windows version of runtime loading of jogl dll (meaning that the user have the choice or not to enable hardware acceleration at runtime)

http://dzzd.net/demo/QUAKE/ just click the applet move/run than use H or S keys to switch from software/hardware mode, it use jogl for hardware rendering.

We have not works on the hardware implementation for a long time but there are a lot of improvment in the soft engine (wich is not online for now… ) wich are for now unavailable in hardware mode, anyways there will be a new demo and beta version soon donwloadable. I hope you will love it :wink:

I will try to get some time to polish and post to the jogl community the part of the code that made runtime loading, this way user will be less afraid as the applet will have already start.

Bruno

#13

Hi Bruno,

the demo is absolutely mindblowing! I have tested it on two machines, on one the sw and hw mode made no
difference (a latest generation PC), on my older PC, in sw mode the texturing seemed to be GL_NEAREST
while in hw it was perhaps GL_MIPMAP (much nicer at least). So perhaps you added some autodetect
for the performance? Very cool! I’d love to test this version ASAP! Good man!

Toni

#14

This is cool, or at least was after I cleaned the puke off my monitor (the camera control is way too touchy). The switching between software and hardware rendering is pretty slick.

Please do. We should start posting this stuff in a more permanent place. I’m hesitant to start using the JOGL Wiki as it never really took off and we’re probably going to recategorize it. If you do a writeup I could give you Developer access to the jogl-demos or joglutils projects and we could start checking in more documentation there.

#15

Yes, tying JOGL to the glacial release cycle of the JRE is my main concern. It’s completely unnecessary and would be very counterproductive to the community.

We’re already most of the way there today, at least from the end user’s standpoint. You can either click to launch (via Java Web Start) or visit to launch (via applets) content using JOGL with zero manual installation already. Again we are working on refining the technologies in particular in the applet arena.

#16

anyways this is an obselete 3DzzD version, so as you can guess next release will have a lot of fixed bug and improvmentn this one will be available soon to download.

note that thijs is doing most of the works, he said that it should be faster to do this times, as the code seems cleaner than last source code we downloaded, last time we works on the runtime loading of JOGL., this code should be released soon :slight_smile:

#17

Hi,

finally finished a working version… before a new release of jogl.

First of all we made a little mistake and compile the jogl.jar with JDK 1.6, this means that hardware rendering and compile of sample provided will only works with JDK1.6

About 3DzzD:
3DzzD now include this feature, demo available here (apologies but JRE 1.6 only for hardware until we recompile with JDK 1.4 or a next release of jogl with those new files :slight_smile: )
http://dzzd.net/demo/V2007-08-18/

the demo will start in full Java 1.1 compatible mode, and than you will be able to switch to hardware using H key (S to get back to software)

FPS: it is limited to 50 fps in either software and hardware mode because when swithing to hardware FPS is growing too much and control become impossible, (NB: quake level test show about 300/400 fps with an ATI x200 using hardware mode… of course…).

Know bugs: multiple switching is not recommended…

note : as it is a WIP (3DzzD V2.0) all software optimisation have been removed and so the software engine can appear to be a bit slower than before, optimisation will be putted back when 3DzzD-V2.0 will be released.

About JOGL
Ken,

they are only two file that have to be added to the jogl package to enable runtime loading of JOGL within an applet, I have put those files in my server to make it easier to download:

they must be added in the following directory of jogl project “src/classes/com/sun/opengl/util” (of course…)

here you can download the source code of the two requiered files:
http://dzzd.net/jogl/JOGLAppletContainer.java
http://dzzd.net/jogl/JOGLAppletLauncher.java

Directory access:
http://dzzd.net/jogl/

How to use it
also I provide this file as an utility that does not requiere to be in the jogl release, it show how to load JOGL from an applet at runtime:
http://dzzd.net/jogl/JOGLAppletLoader.java

you may download a sample project and source code there:
RuntimeJoglAppletSample.zip

once again , I apologize for the 1.6 JRE/JDK requierment.

waiting feed back!

special thank to thijs: he has coded and compiled the two new jogl library files

#18

Thanks for posting this. However, we have recently released the new JNLPAppletLauncher which I believe solves this problem more elegantly. This class does not load the native libraries up front (although it does currently download them from the server up front) so it should support the lazy loading that your modifications enable. Please take a look at the JNLPAppletLauncher and see whether it serves your needs. I would prefer not to make any more changes to the JOGLAppletLauncher as I am planning to remove it from the source tree.

#19

[quote]Thanks for posting this. However, we have recently released the new JNLPAppletLauncher which I believe solves this problem more elegantly. This class does not load the native libraries up front (although it does currently download them from the server up front) so it should support the lazy loading that your modifications enable. Please take a look at the JNLPAppletLauncher and see whether it serves your needs. I would prefer not to make any more changes to the JOGLAppletLauncher as I am planning to remove it from the source tree.
[/quote]
Hi Ken,

The new JNLPAppletLauncher is indeed a step forward, but for our specific case it wouldn’t solve our problem. In our case JOGL is just a driver to render over opengl. There are some reasons why we chosen to implement it like this:

1.) The JNLPAppletLauncher would force us to load our applet through another applet. Something that would put restrictions on backward compatibility (for example, in our case jre 1.1 compatibility)

2.) We dont want to narrow our framework to be JOGL specific (hence not load as a subapplet from JOGL). Another driver to render things would be through LWJGL, maybe the upcomming DirectX binding or our software renderer. This is why we want our own applet to be in control and force these “drivers” to load when a user requests so (like when you chose another renderer in fx unreal).

3.) We want to keep the applet loading and booting as fast as possible, when a user asks to do things over jogl or lwjgl, only then download and install this driver (when not yet present). JNLPAppletLauncher downloads everything upfront… also the jars in the archive param now can be downloaded at runtime using our approach (wip)

4.) We want to be in control of how this downloading/installing progress gets visualized to the user… for example through our own GUI system (not through Swing as JNLPAppletLauncher imposes).

5.) We dont want to require our applet to popup an security warning initially (we run using the software renderer at default)… only when the user requests this explicitly this warning should be raised before downloading and installing the driver.

At the moment I’m refining the current implementation to help achieving this even better than it does now… We’ll release it as opensource, so people with the same goals as set out above can use that instead (though need to sign the jars with their own certificate)

Thijs

#20

I see.

The JNLPAppletLauncher knows nothing about JOGL. LWJGL could easily be modified to work with the JNLPAppletLauncher, and the libraries aren’t loaded until the code which requests for example the JOGL native libraries actually loads them.

If you would be willing to share your code for this technique when it’s done I would very much appreciate it. This seems like a pretty hard problem in my experience.

Understood, agreed.

That would be really nice. Looking forward to seeing it.