JOGL and JNLP

OpenGL Development JOGL Development
#1

Hi all!

I’m working on a RIA launched trough JWS.

The application is a really big one and is developed by many people and it’s based on SWING. I’m working on a GIS component based on JOGL.

With JRE 1.6.0_12+

…and by using

-Dsun.java2d.noddraw=true -Dsun.java2d.opengl=true

…options I managed to get a GLCanvas into a Swing Internal Frame (Internal Frames are mandatory for this app) with full OpenGL acceleration.

BUT! This works only by running the client from the development environment.

JNLP doesn’t seem to accept those parameters and the same interface runs many times slower if launched through JWS. I found in a forum that Java 6 should accept both parameters as “secure” and send them to the JVM in the command line but it doesn’t look it really happens.

I tried putting them in the JNLP as “property” tags:

` 

(...)

<property name="sun.java2d.noddraw" value="true"/>
<property name="sun.java2d.opengl" value="true"/>
`

…and also tried in java-vm-args attribute:

`
<j2se java-vm-args="-XX:MaxPermSize=512m -Xcheck:jni" -Dsun.java2d.noddraw=true -Dsun.java2d.opengl=true max-heap-size=“1024M” version=“1.4+”/>

(...)
`

…but nothing.

Anyone has faced similar problems with JNLP? :’(

#2

Are all your jars signed?

Cas :slight_smile:

#3

Yes Princec,

We sign all jars (jogl included) during the deploy phase. In fact we have no issues related to jar signature or missing classes. Everything works, but slow.

We are currently using JOGL 1.1.1 and we are forced to compile our application with JDK 1.4 because we are stuck with JBoss 3.2.5 version. Anyway, client machines run on JRE 1.6.0_16+ (JWS included).

I dont know if this can be the cause of my problems but, as said, from the development environment (JDeveloper) everything works.

Moreover… is there a mean to programmatically understand if the openGL acceleration is on? I can check it only by visually comparing two instances of the application side by side, one launched by JDev, the other one launched by JWS. This can lead to some issues with customers, if I cannot tell them that they have problems with accelerated GL.

I tried by checking if System.getProperty( “sun.java2d.noddraw” ) and System.getProperty( “sun.java2d.opengl” ) return “true” value and by checking the JRE version but that’s not enough because this check tells that everything is okay with JNLP configured as previous message but it really doesn’t.

Umberto.

#4

Hi!

I use this:

<property name="sun.java2d.noddraw" value="true"/>

and sometimes this:

System.setProperty("sun.java2d.noddraw","true");

In my case, it works but you will have to compile your application with a more recent version of the JDK to solve your problem, there is no other solution in my humble opinion.

You say it is slow but are you sure it has something to do with this flag?

#5

I’m not sure that would help.

Isn’t this that thing where even though the properties are set, they don’t have any effect because Java2D has already been initialised by the webstart interface? IIRC the solution is to spawn your own JVM where you can be sure that the properties are in place before Java2D is initialised.

#6

This should not be necessary (this bug has been fixed or I would have the same problem) and my suggestion works in my case. Maybe uuderzo should test your suggestion by launching his application in command line outside his IDE only with the JARs.

#7

@gouessej: I’m not sure that the slowness is related to the flag, but this is the only possible problem I found searching through forums.

@bleb: I guess this is related to the issue you reported, that should be fixed in JRE 6. Since I’m using 1.6.0_16 the problem shold not be this one… but I dont’ know whatever could be.

There is a slight difference between the IDE environment and the JWS environment:

For the IDE to work properly, I had to put the native code (DLLs) into a path-ed folder. On the other hand, for JNLP properly to work, the DLLs are packed into a jar referred by the JNLP file.

All jars are hosted in our web server (no external references) because our customers operate in a secured environment with likely no access to the internet (only local network).

I’ll try to launch the app by a batch file and see what happens, then post results here.

Anyway… no way to programmatically detect if acceleration is on, and if PBuffer copy is used?

#8

Well… that’s weird indeed.

Done a frame rate test (maximized swing internal frame containing GLCanvas component and a relatively heavy model) launching the application from batch file, from JDev and from JWS.
For each case I tested both with flags (-Dsun.java2d.noddraw=true -Dsun.java2d.opengl=true) and not (for JNLP used the property tag to specify the flags)

Used JRE 1.6.0_19 for all cases.

Here the results:

[tr][td][/td][td]With flags[/td][td]Without flags[/td][/tr]
[tr][td]Batch[/td][td]125ms[/td][td]125ms[/td][/tr]
[tr][td]JDev[/td][td]125ms[/td][td]125ms[/td][/tr]
[tr][td]JWS[/td][td]250ms[/td][td]250ms[/td][/tr]

Numbers are the average rendering time per single frame.

Results are pretty strange… Looks like the presence of the flags is ininfluent and in each test the JWS version is twice slower.

Well… the only difference between JWS and rest of the world is the way DLLs are delivered to the client. May this be the issue?

#9

well, you are using a GLCanvas thats why -Dsun.java2d.opengl=true has no influence. The Canvas already uses the fastest path. -Dsun.java2d.noddraw=true shouldn’t change anything on the performance also, its only there to circumvent some bugs on windows.

regarding JWS… don’t know why this happenes but 250ms are… well long :wink: it would be interesting to know if this also happens with a simpler scene.
You could also try an older version of java 6 without the strange JWS exclamation marks rendered as overlay… just to exclude third party issues.

(btw if you are spending more than 2s for rendering you could trigger on windows a feature which will kill and restart the graphics driver)

#10

Well, that -Dsun.java2d.opengl=true is useless with latest JRE and GLPanel that’s good news.

And for -Dsun.java2d.noddraw=true, I should try deploying the app without it and add it only if customers have problems. Good indeed.

I converted the performance test algorithm to FPS, so it’s more understandable.

Well…

test with huge model in JWS = 3.7 fps, rest of the world = 6.7 fps
test with simple model in JWS = 32 fps, rest of the world = 60 fps

There’s definitely something strange with JWS that gives half the performance, but cannot guess what it can be…

Umberto

#11

you said you are using the GLCanvas. You might still see performance improvements by using -Dsun.java2d.opengl=true on a GLJPanel since it removes an additional copy operation.

but it won’t help in your case since there is clearly something else involved… Maybe its a performance bottleneck in the InternalFrame implementation etc. Without profiling it will be hard to find the issue.

#12

Well… I think that I cannot go futher on this issue… too bad time is lacking for this project.

Hope being able to find something in future.

Thank you for your support bienator!

Umberto