WebStart, VM options & J2D

Java 2D
#21

what do you mean 3 versions? If pipelines can’t be abled programaticly you assume user will relaunch JVM? …If so, maybe you can read what settings are set and run appropriate rendering engine.

#22

You could probably use Runtime.exec() to launch a new VM process.
I haven’t done this from a JWS app, though.

Something like this:


          String classPath = System.getProperty("java.class.path",".") + " "; // this may need to be tweaked
          String opt = "-Dsun.java2d.d3d=true MyMegaApp"; // or whatever
          String cmd = new String(System.getProperty("java.home") +
                                  File.separator +
                                  "bin" +
                                  File.separator +
                                  "java -cp " + classPath +
                                  opt);
          try {
              childProc = Runtime.getRuntime().exec(cmd);
              childProc.waitFor();
          } catch (Exception e) {
              e.printStackTrace();
          }

Make sure you read stderror and stdout streams, otherwise your child
process will hang. Look around for samples on how to use Runtime.exec().

But really, I think that having 3 jnlp files isn’t that bad an alternative, given that
you’ll have two VMs running otherwise.

Thanks,
Dmitri

#23

I worry that having 3 versions of the same program will just confuse the user. If only the programmatic System.setProperty() way of setting java2D flags worked with webstart, then yours & Chris C’s awesome work on the OGL & directdraw/d3d pipelines could be unleashed!

Thanks, I’ve got similar code that I put up earlier in this thread but the classpath doesn’t come out properly in webstart, as you commented above. I’ve been looking into how the classpath can be gotten from a webstarted app but it looks impossible since I can’t find a way of telling where that jar file that contains the classes is stored… Also, Runtime.exec(“bin/java.exe MyJar.jar”) is platform specific, which is a pity.

Thanks for the help,
Keith

#24

Never ever use the single argument version of Runtime.exec().
You are bound to make assumptions about how the arguments are split based on the shell you use, but Runtime.exec(cmd) is not a shell and does not parse arguments the same way. If there was a space in the “java.home” path or “java.class.path”… which there usually is on Windows (e.g. “C:\ Program Files…”) then the version used above will fail miserably.

Use the version of Runtime.exec that takes an array for the arguments. It’s much safer.

#25

Hi Dmitri and Chris,

We need a way to know what Java2D options will be the fastest (default vs noddraw vs opengl). Also, we need a way to switch VM options programmatically even after Web Start has launched (ie a System.setProperty(…) thing that is actually honoured). The reason is that Java2D does have the performance to make a game run fast, but the VM options are crucial to squeezing the most out. I’ve trialled my game on lots of different computers and had the following results, which vary a lot depending on the options.

On crap or non-video card computers (~2GHz processor) my game runs at 2 FPS with no options. In noddraw mode it runs at about 15 FPS. On good computers with good video cards or fast processors opengl-pipeline mode & also the noddraw mode run at between 40-70FPS. The game is here: http://www.freewebs.com/commanderkeith/STG.jnlp

Can you work out a way to set the VM options programmatically and/or a way to work out which one is best? A work around would be a way to relaunch the VM but that can’t be done with WebStart & its caching as far as i can tell.

Thanks,
Keith

#26

Do you mean, for now or for future release?

Unfortunately currently I don’t think there’s a single option which would
work everywhere consistently because of so many variables involved
(what the game does, cpu, video board, driver) - except for may be for the
noddraw=true - it’s pretty consistent in the sense that the faster the system’s CPU
the faster your game will run.

So if the lowest denominator is 15fps and it’s acceptable, I would
suggest using the noddraw mode.

Has it already been suggested having separate jnlp files for each
configuration (with opengl, d3d or noddraw)? I agree that it ain’t pretty,
and opengl and d3d will only work on mustang (which confuses the matters
even more)…

As for future releases, I completely agree, we need some better
way of selecting the pipelines.

Thanks,
Dmitri

#27

Thanks for considering this problem.

As a work around for now, it would be good enough if there was a way to programmatically

  1. re-launch the VM from within Web Start or
  2. make WebStart honour the System.setProperty flags.

That way we could detect which mode was the best & try others if we want. Currently, we can’t even re-launch our game with a new (optioned) VM since Runtime.exec(…) can’t be given the jar file of our game because (as far as I know) Web Start caches it in a black hole >:(. I know Web Start isn’t your field, but its holding us back from showing off how good Java2D can be. Maybe you could have a word with the deployment guys?

Many thanks,
Keith