JOGL Applet Launcher memory issues

Hi,

we’re using JOGL Applet Launcher to deploy an JOGL-project as an applet. Most clients have no problem running the applet, but some computers with Mobile Intel graphics cards especially have some problems in Internet Explorer when -Xmx is set. I tested the applet on an Mobile Intel 915/GMS, 910GML Express Chipset Family, with over 700 MB RAM, and had -Xmx128m specified. The result is that when creating a GLCanvas, we only get a software GDI canvas, and not an hardware accelerated canvas! This is only in Internet Explorer, the same settings works in Firefox and also stand alone on the desktop.

Is this an known issue?

Regards,
Johan Göransson
Agency9

There have been some known issues with applets and large heap sizes in Internet Explorer for a while. Unfortunately I wasn’t able to dig up a bug ID though. The basic problem appears to be that in some situations IE loads a DLL at a really bad point in the 32-bit address space which causes various problems. The worst is that the Java heap can’t be allocated. Another appears to be the one you’ve run into where the graphics driver apparently can’t initialize properly.

We are working on a solution to this problem in the core JRE. Please bear with us for a little while longer. In the meantime please offer a Java Web Start version of your app as a workaround for people who run into this and similar problems.

Hi Ken,

thank you for your reply.
Unfortunately a web start deployment strategy isn’t suitable for our project, since we have to be embedded in a web page. We’re trying to figure out possible work-arounds.

Is this bug only affecting jogl-applets or applets in general? Could we switch to D3D-rendering or software-rendering?
Would it be possible to write our own java plugin to IE, i.e. an activex plugin using jni to get our java project running in a browser, or would we face the same bug?

Regards,

Johan Göransson
Agency9

The problem is a general one, though the specific symptoms likely differ. The worst one would be an inability of the JVM to start. I doubt you’re going to solve it by writing your own Java plugin, which is a very large task (at least to get the functionality of the Sun Java Plug-In like Java/JavaScript interoperability and many other features).

If you remove the -Xmx flag and use the default 64 MB heap size, do you get hardware acceleration? In other words, the -Xmx128m flag is definitely what’s causing the Intel graphics drivers to stop working?

Its definitely the -Xmx flag, tested on two different computers with intel graphics. Removing the flag results in hardware accelerated context.

If we were to write our own plugin, it would not be as extensive as suns, it would only be able to run our special java class, and nothing else. If it could solve the problem, it would be worth the development time.
But if the problem is in the jvm.dll, I guess we would have the same issue anyway.

Hi,

Sorry for bringing up this thread again but was this issue a bug in IE, Java plugin or the jvm.dll ?
Since I hope that we don’t have to abandon Java to reach our miletsone…

Thanks for you help Ken
// Tomas.

It’s poor interaction between IE, the graphics drivers, and the JVM.

Java applications deployed via Java Web Start are unaffected.

We are working on a solution to this problem, but it’s more than a couple of months away.

I certainly don’t want to lose your deployments in the meantime, but if there is any way for you to use Java Web Start instead of applet-based deployment for now then please go that route. If you must use an applet (why?), and absolutely need a workaround, I have a fairly radical suggestion which I’d prefer not to post on the forum. Please contact me at kbr at dev dot java dot net if you’d like me to describe it.