We are adjusting the Mac app bundle to be launchable with either Apple’s Java 5 or Java 6, or Oracle’s Java 7, rather than exclusively using Apple’s Java 5 or 6 as it does now. We’d like to have your help testing this.
2013-11-07 07:47:20,717 [0-main] INFO VASSAL.launch.StartUp - Starting
2013-11-07 07:47:20,776 [0-main] INFO VASSAL.launch.StartUp - OS Mac OS X 10.9
2013-11-07 07:47:20,776 [0-main] INFO VASSAL.launch.StartUp - Java version 1.7.0_45
2013-11-07 07:47:20,776 [0-main] INFO VASSAL.launch.StartUp - VASSAL version 3.2.9-svn8901
The module manager seems fine and functional.
The icons of the launched modules are the default Java icon instead of the VASSAL icon.
The graphics are horribly slow. Drawing of the board tiles can be tracked visually step by step. Dragging pieces in some modules is almost beyond playable – dragging a piece you have to hold it for several seconds to prevent events being missed due to slowness. Drawing a selection box around pieces can be measured in seconds instead of ms. Etc.
I tried Memoir '44 10.8r3 (3.1.20), No Retreat! 1.4.1 (3.1.19)
With a module from 3.2.x the graphics seemed to be alright: Combat Commander: Europe 2.3 (3.2.6), BUT the drag events were still often missed, meaning I’d drag a piece, and it’d return to its original position about 1/3rd of the drags.
The icons of the launched modules are the default Java icon instead of
the VASSAL icon.
Could you post the complete errorLog from a run where you open a
module? I want to see who the Player is being launched.
The graphics are horribly slow. Drawing of the board tiles can be
tracked visually step by step. Dragging pieces in some modules is almost
beyond playable – dragging a piece you have to hold it for several
seconds to prevent events being missed due to slowness. Drawing a
selection box around pieces can be measured in seconds instead of ms.
Etc.
I tried Memoir '44 10.8r3 (3.1.20), No Retreat! 1.4.1 (3.1.19)
With a module from 3.2.x the graphics seemed to be alright: Combat
Commander: Europe 2.3 (3.2.6), BUT the drag events were still often
missed, meaning I’d drag a piece, and it’d return to its original
position about 1/3rd of the drags.
Does this happen if you run the generic version of the same build
with Java 7?
In 3.2.9-8901 and 3.2.9-8905, both the module manager and the player use Java version 1.7.0_45. The icon has been fixed in 8905 (it shows the name in the dock as “java” but it did so with 3.2.8 as well).
In 3.2.9-8905 I wanted to think the speed is better than with 3.2.9-8901, but comparing again to 3.2.9-8901 I think it was wishful thinking (you probably didn’t change anything for this?). It’s still noticably much slower than 3.2.8 with selecting and moving pieces/cards, and especially noticable when scrolling boards. Also in 3.2.9-8905 (and 8901) if I drag a card from the draw deck it’ll draw a selection rectangle at the same time and select units (every time). I’d not call it playable.
Tried Combat Commander: Europe with 3.2.9-8905 and it also had pretty much the same problems as before.
In 3.2.9-8901 and 3.2.9-8905, both the module manager and the player use
Java version 1.7.0_45. The icon has been fixed in 8905 (it shows the
name in the dock as “java” but it did so with 3.2.8 as well).
I wasn’t aware the name was wrong in 3.2.8. Is this the name of the
Module Manager or of the Player?
In 3.2.9-8905 I wanted to think the speed is better than with
3.2.9-8901, but comparing again to 3.2.9-8901 I think it was wishful
thinking (you probably didn’t change anything for this?).
No, the only change between 8901 and 8905 was to set the working
directory for the JVM in order to help it find the dock icon. But there
have also been no changes since 3.2.8 to anything which draws graphics
on the screen.
It’s still
noticably much slower than 3.2.8 with selecting and moving pieces/cards,
and especially noticable when scrolling boards. Also in 3.2.9-8905 (and
8901) if I drag a card from the draw deck it’ll draw a selection
rectangle at the same time and select units (every time). I’d not call
it playable.
Is the 3.2.8 with which you are comparing the Mac app bundle? What
version of Java is 3.2.8 using when you run it?
Modules launched from the module manager have the VASSAL icon but the name in the dock and application switcher is “java”. The name is correct on the application menu in the player.
Also, I am not sure if I remember this correctly, but in 3.2.8 it’s possible to launch multiple instances of the same module. I thought before this was limited to one player instance per vmod?
The 3.2.8 I am using is the app bundle from the current release dmg distribution.
My 3.2.8 uses Java version 1.6.0_65 for the module manager and the player.
I wasn’t aware the name was wrong in 3.2.8. Is this the name of the
Module Manager or of the Player?
Modules launched from the module manager have the VASSAL icon but the
name in the dock and application switcher is “java”. The name is correct
on the application menu.
Ok. Looking into this now.
Also, I am not sure if I remember this correctly, but in 3.2.8 it’s
possible to launch multiple instances of the same module. I thought
before this was limited to one player instance per vmod?
It’s been possible to launch multiple instances of the same module
since 3.2.0.
The 3.2.8 I am using is the app bundle from the current release dmg
distribution.
My 3.2.8 uses Java version 1.6.0_65 for the module manager and the
player.
Can you run the generic 3.2.8 bundle in Java 7 and check the performance
of that?
In 3.2.9-8901 and 3.2.9-8905, both the module manager and the player
use
Java version 1.7.0_45. The icon has been fixed in 8905 (it shows the
name in the dock as “java” but it did so with 3.2.8 as well).
I wasn’t aware the name was wrong in 3.2.8. Is this the name of the
Module Manager or of the Player?
Modules launched from the module manager have the VASSAL icon but the
name in the dock and application switcher is “java”. The name is correct
on the application menu in the player.
Hmm. We’re already using -Xdock:name to set the module name when we
launch the Player, which everything I’ve read says is the way to set
this, but apparently it’s being ignored.
It attempts to turn on the Quartz renderer. I’m not sure that Java 7
respects the settings for this, but it’s the only thing I can think
of trying. Do you see any performance difference this way?
It attempts to turn on the Quartz renderer. I’m not sure that Java 7
respects the settings for this, but it’s the only thing I can think
of trying. Do you see any performance difference this way?
(Try the generic ZIP archives, not the app bundles, so that you can run
them with Java 7.) If you find any which don’t exhibit the problem, then
try to find the most recent one which doesn’t. That way, if the problem
you’re seeing is caused by any changes we made, we can narrow the range
of commits where they happened.
3.1.20 works, as soon as I go to 3.2.0 it slows down. Both run in Java
1.7.
3.2 has a completely different graphics subsystem from 3.1, so
unfortunately that’s not going to help us track down changes. (The
answer to what changed between 3.1 and 3.2 is: Everything.) So, it
looks like there’s some bad interaction between that, Java 7, and
something else on your Mac.
So far, yours is the sole report of this problem with 3.2 and Java 7.
There has to be some difference between your Mac and the Macs where
it works.
Did you check on whether your drivers, firmware, etc. are current?
The Mac where I know Java 7 is working does not have a Retina display. I’ll bet that you and Quisition both have Retina displays. In 3.2.2, we introduced a workaround for a bug in Apple’s Java 6 which prevented map tiles from painting correctly. If that bug is fixed in Java 7, then our workaround is no longer appropriate for anyone running Java 7 on a Mac with a Retina display. Here’s a build which removes the special behavior for Retina displays: