3.2.11 Mac too slow (+ other oddity)

3.2.11 is considerably slower again than 3.2.10. Not as much as with the OpenGL problems before, but too slow to use. Drag box for selection, selecting pieces, dragging pieces, drawing large background images, is all visibly and noticeably too slow.

As an added oddity, the prompt dialogs (do you want to save, enter a label value, etc) used to show the VASSAL icon on the left, but now show an OS X folder icon.

Using Memoir '44 Module on OS X 10.9.1, 2.93 GHz Core i7 iMac 27", 8GB RAM (1333 Mhz DDR3), ATI Radeon HD 5750 1024 MB.

Thus spake bdgza:

3.2.11 is considerably slower again than 3.2.10. Not as much as with the
OpenGL problems before, but too slow to use. Drag box for selection,
selecting pieces, dragging pieces, drawing large background images, is
all visibly and noticeably too slow.

As an added oddity, the prompt dialogs (do you want to save, enter a
label value, etc) used to show the VASSAL icon on the left, but now show
an OS X folder icon.

Using Memoir '44 Module on OS X 10.9.1, 2.93 GHz Core i7 iMac 27", 8GB
RAM (1333 Mhz DDR3), ATI Radeon HD 5750 1024 MB.

Please check in the errorLog what version of Java VASSAL 3.2.11 is
actually using, and also tell us what version you expect it to be
using.


J.

Java version 1.6.0_65
VASSAL version 3.2.10

Java version 1.7.0_45
VASSAL version 3.2.11

Edit: I’ve patched my VASSAL.sh to use 1.6.0_65, so it’s fast again

Thus spake bdgza:

Java version 1.6.0_65
VASSAL version 3.2.10

Java version 1.7.0_45
VASSAL version 3.2.11

This is exactly what I expected had happend. We made a small change
to the launch script to accomodate old Macs which have only Java 5;
apparently this caused a problem for Macs which have both Java 6 and
Java 7.

Please post the output of the following:

ls -l /System/Library/Frameworks/JavaVM.framework/Versions/


J.

ls -l /System/Library/Frameworks/JavaVM.framework/Versions/
total 64
lrwxr-xr-x 1 root wheel 10 25 Oct 13:14 1.4 → CurrentJDK
lrwxr-xr-x 1 root wheel 10 25 Oct 13:14 1.4.2 → CurrentJDK
lrwxr-xr-x 1 root wheel 10 25 Oct 13:14 1.5 → CurrentJDK
lrwxr-xr-x 1 root wheel 10 25 Oct 13:14 1.5.0 → CurrentJDK
lrwxr-xr-x 1 root wheel 10 25 Oct 13:14 1.6 → CurrentJDK
lrwxr-xr-x 1 root wheel 10 25 Oct 13:14 1.6.0 → CurrentJDK
drwxr-xr-x 7 root wheel 238 25 Oct 13:14 A
lrwxr-xr-x 1 root wheel 1 25 Oct 13:14 Current → A
lrwxr-xr-x 1 root wheel 59 25 Oct 13:14 CurrentJDK → /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents

Thus spake bdgza:

ls -l /System/Library/Frameworks/JavaVM.framework/Versions/
total 64
lrwxr-xr-x 1 root wheel 10 25 Oct 13:14 1.4 → CurrentJDK
lrwxr-xr-x 1 root wheel 10 25 Oct 13:14 1.4.2 → CurrentJDK
lrwxr-xr-x 1 root wheel 10 25 Oct 13:14 1.5 → CurrentJDK
lrwxr-xr-x 1 root wheel 10 25 Oct 13:14 1.5.0 → CurrentJDK
lrwxr-xr-x 1 root wheel 10 25 Oct 13:14 1.6 → CurrentJDK
lrwxr-xr-x 1 root wheel 10 25 Oct 13:14 1.6.0 → CurrentJDK
drwxr-xr-x 7 root wheel 238 25 Oct 13:14 A
lrwxr-xr-x 1 root wheel 1 25 Oct 13:14 Current → A
lrwxr-xr-x 1 root wheel 59 25 Oct 13:14 CurrentJDK →
/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents

Aha. I see why you’re launching with Java 7: You have an Apple JDK,
but our launcher script looks only for JREs. I’ve noted this as Bug
10867.

Try 3.2.12-svn9013:

vassalengine.sourceforge.net/bui … macosx.dmg


J.

No, 3.2.12-9013 still launches with Java 7.

Thus spake bdgza:

“uckelman” wrote:

Thus spake bdgza:

ls -l /System/Library/Frameworks/JavaVM.framework/Versions/
total 64
lrwxr-xr-x 1 root wheel 10 25 Oct 13:14 1.4 → CurrentJDK
lrwxr-xr-x 1 root wheel 10 25 Oct 13:14 1.4.2 → CurrentJDK
lrwxr-xr-x 1 root wheel 10 25 Oct 13:14 1.5 → CurrentJDK
lrwxr-xr-x 1 root wheel 10 25 Oct 13:14 1.5.0 → CurrentJDK
lrwxr-xr-x 1 root wheel 10 25 Oct 13:14 1.6 → CurrentJDK
lrwxr-xr-x 1 root wheel 10 25 Oct 13:14 1.6.0 → CurrentJDK
drwxr-xr-x 7 root wheel 238 25 Oct 13:14 A
lrwxr-xr-x 1 root wheel 1 25 Oct 13:14 Current → A
lrwxr-xr-x 1 root wheel 59 25 Oct 13:14 CurrentJDK →
/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents

Aha. I see why you’re launching with Java 7: You have an Apple JDK,
but our launcher script looks only for JREs. I’ve noted this as Bug
10867.

Try 3.2.12-svn9013:

vassalengine.sourceforge.net/bui … macosx.dmg[1]


J.

No, 3.2.12-9013 still launches with Java 7.

Would you mind looking at the launch script and telling me what’s wrong,
then?


J.

Java 7 is at:
JAVA="/System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/java"

So it will take the current (7) version and launch that before trying JDK 6.

I can’t remember now if this is a normal setup or if I changed this manually for some reason to get something else to work (or attempt to work). Java is a pile of steaming manure :frowning:. If it’s just me then I’ll change the launch script myself to get it to work.

Edit: I checked on my other Mac with 3.2.12-9013 and it launches with Java 6. So I think it’s just what I did to my iMac that is causing this.

Thus spake bdgza:

I can’t remember now if this is a normal setup or if I changed this
manually for some reason to get something else to work (or attempt to
work). Java is a pile of steaming manure :(.

Concur. I’ll be so happy to see the back of it. It’s the height of
irony that the time I spend dealing with platform-specific issues these
days is mostly involves a language and libraries which are supposedly
platform-independent.

Edit: I checked on my other Mac with 3.2.12-9013 and it launches with
Java 6. So I think it’s just what I did to my iMac that is causing this.

Yes, I suspect that you adjusted the links yourself. I would argue that
Oracle’s Java 7 ought to do that when it’s installed, but as it
doesn’t, we have to assume that no one will have these.

Anyway, I’m happy to know about the CurrentJDK links—we now check
there as well, so we shouldn’t get any complaints about VASASL not
starting for people with a JDK but no JRE.


J.

Even with that version I get the error message with suggestion I should I install Java SE 6 in spite of having Java 7 already installed.
Vassal 3.2.10 is the latest version working for me at the moment (albeit with terribly laggy scrolling).

/Quisition

Thus spake Quisition:

“uckelman” wrote:

Thus spake bdgza:

ls -l /System/Library/Frameworks/JavaVM.framework/Versions/
total 64
lrwxr-xr-x 1 root wheel 10 25 Oct 13:14 1.4 → CurrentJDK
lrwxr-xr-x 1 root wheel 10 25 Oct 13:14 1.4.2 → CurrentJDK
lrwxr-xr-x 1 root wheel 10 25 Oct 13:14 1.5 → CurrentJDK
lrwxr-xr-x 1 root wheel 10 25 Oct 13:14 1.5.0 → CurrentJDK
lrwxr-xr-x 1 root wheel 10 25 Oct 13:14 1.6 → CurrentJDK
lrwxr-xr-x 1 root wheel 10 25 Oct 13:14 1.6.0 → CurrentJDK
drwxr-xr-x 7 root wheel 238 25 Oct 13:14 A
lrwxr-xr-x 1 root wheel 1 25 Oct 13:14 Current → A
lrwxr-xr-x 1 root wheel 59 25 Oct 13:14 CurrentJDK →
/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents

Aha. I see why you’re launching with Java 7: You have an Apple JDK,
but our launcher script looks only for JREs. I’ve noted this as Bug
10867.

Try 3.2.12-svn9013:

vassalengine.sourceforge.net/bui … macosx.dmg[1]


J.

Even with that version I get the error message with suggestion I should
I install Java SE 6 in spite of having Java 7 already installed.

Please tell me what all of the symbolic links in your
/System/Library/Frameworks/JavaVM.framework/Versions/ point to. I
can’t make any progress without knowing that.

Vassal 3.2.10 is the latest version working for me at the moment (albeit
with terribly laggy scrolling).

Poor graphics performance with Java 7 happens only on some Macs and
isn’t our bug, so far as I can see. It’s also unlikely to be the kind
of thing we can work around. I think it’s likely that it’s Oracle’s
problem, which doesn’t make me optimistic that it will be fixed. The
solution I see for this is to use Java 6 until VASSAL 4.


J.

[computer]$ l /System/Library/Frameworks/JavaVM.framework/Versions/
total 4
0 drwxr-xr-x 8 root wheel 272 10 Nov 19:57 A/
4 lrwxr-xr-x 1 root wheel 1 10 Nov 19:57 Current@ → A
[computer]$ l /System/Library/Frameworks/JavaVM.framework/Versions/A
total 36
0 drwxr-xr-x 44 root wheel 1496 25 Aug 2013 Commands/
0 drwxr-xr-x 4 root wheel 136 10 Nov 13:45 Frameworks/
0 drwxr-xr-x 3 root wheel 102 25 Aug 2013 JavaPluginCocoa.bundle/
36 -rwxr-xr-x 1 root wheel 99792 10 Nov 19:57 JavaVM*
0 drwxr-xr-x 44 root wheel 1496 10 Nov 19:57 Resources/
0 drwxr-xr-x 3 root wheel 102 25 Aug 2013 _CodeSignature/
[computer]$

This is with 10.9 fresh installation and just Oracle’s Java 7 JRE installed.

Yes, I have understood that, not accepted it yet though… =)

Thus spake Quisition:

[computer]$ l /System/Library/Frameworks/JavaVM.framework/Versions/
total 4
0 drwxr-xr-x 8 root wheel 272 10 Nov 19:57 A/
4 lrwxr-xr-x 1 root wheel 1 10 Nov 19:57 Current@ → A
[computer]$ l /System/Library/Frameworks/JavaVM.framework/Versions/A
total 36
0 drwxr-xr-x 44 root wheel 1496 25 Aug 2013 Commands/
0 drwxr-xr-x 4 root wheel 136 10 Nov 13:45 Frameworks/
0 drwxr-xr-x 3 root wheel 102 25 Aug 2013
JavaPluginCocoa.bundle/
36 -rwxr-xr-x 1 root wheel 99792 10 Nov 19:57 JavaVM*
0 drwxr-xr-x 44 root wheel 1496 10 Nov 19:57 Resources/
0 drwxr-xr-x 3 root wheel 102 25 Aug 2013 _CodeSignature/
[computer]$

This is with 10.9 fresh installation and just Oracle’s Java 7 JRE
installed.

Oh, that’s neat. They have Current/Commands/java pointing to something
which tells you that you don’t have Java. So NOW YOU CAN’T CHECK THAT
TO TELL WHETHER YOU DO! ARGH!

It takes some effort to make it this difficult to determine whether a
program is installed. Apple and Oracle can both go DIAF.

Try 3.2.12-svn9019: vassalengine.sourceforge.net/builds/

bdgza, you too—I want to be sure this hasn’t reintroduced the problem
for you.


J.

3.2.12-9019 launches with Java 6 with the stock (unmodified) launch script on my iMac.

Thus spake bdgza:

3.2.12-9019 launches with Java 6 with the stock (unmodified) launch
script on my iMac.

Great. Thanks for confirming.


J.

Check. Works here. Thanks.

Any chance of signing the app “correctly” and getting rid of the “Unidentified developer”-stuff?

Noone would be happier than me if you abandoned Java… As long as you can keep the OS X port still… This is the only Java app I use at the moment.

/Quisition

Thus spake Quisition:

Check. Works here. Thanks.

Great.

Any chance of signing the app “correctly” and getting rid of the
“Unidentified developer”-stuff?

I’ll happily start signing the app if you can suggest a way of doing
that on Linux.

Noone would be happier than me if you abandoned Java… As long as you
can keep the OS X port still… This is the only Java app I use at the
moment.

That’s our intention.


J.

Probably not possible I guess… Signing on Linux I mean… No chance of access to a Mac or even a Hackintosh? =)

Just out of curiosity, what will Vassal 4 be based on instead of Java?

/Quisition

Thus spake Quisition:

Probably not possible I guess… Signing on Linux I mean… No chance of
access to a Mac or even a Hackintosh? =)

People have figured out some of the Mac tools. E.g., we’re able to build
a compressed DMG on Linux. I’m still rather shocked that nobody’s looked
at what exactly codesign is doing and produced something which does the
equivalent.

We don’t happen to have access to a Mac at present, but even if we did,
I wouldn’t use it for codesigning. I’m not interested in having a build
process which can’t all be done in one place.

Just out of curiosity, what will Vassal 4 be based on instead of Java?

On a standard, so that clients can be written in anything. The reference
implementation that I’m planning will be in C++.


J.