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:
I have an iMac 27". None of those have Retina displays yet.
Try that build anyway. It would still be interesting to see if this
change makes a difference. If it doesn’t, then we might have yet
another case where the “preferred” image type reported by Java is
wrong, and we’ll have to try a few of the possibilities.
I have an iMac 27". None of those have Retina displays yet.
Try that build anyway. It would still be interesting to see if this
change makes a difference. If it doesn’t, then we might have yet
another case where the “preferred” image type reported by Java is
wrong, and we’ll have to try a few of the possibilities.
No improvement.
Ok. I have a diagnostic program I’d like you to run in both Java 6
and Java 7, and report back the results. What it does is ask the
JVM to say what it thinks are the preferred image types for the system
on which it runs. (The source is included in the archive, in case you
want to see what’s it’s doing.)
When I run it on my Linux system with Java 7, I get output like so:
[uckelman@scylla compat-image]$ java Test
opaque type == 1
translucent type == 2
This is what I suspected—Java 7 is misreporting the preferred type
for translucent images on your system. Type 2 is ARGB packed as
4-byte integers, type 3 ARGB packed as 4-byte integers with the RGB
premultiplied by the alpha. Years ago, the reason I added the code
for getting the preferred image types from Java rather than hard-coding
it was that some Macs wanted premultiplied ARGB, and were very slow
without it…
With the argb build the drawing speed is better, and while dragging the ghost draw speed is good too. But, there are still many issues, such as:
drawing a selection box, redrawing of the black rectangle is still slow
initiating a drag, you have to hold a piece for about a second before the drag ghost draws (in Memoir '44, in modules with few pieces less of a problem). This makes rapid (small) moves of pieces a pain
drawing is still slower, in No Retreat! (GMT) for example I can see the map tiles slowly fading in after scrolling
scrolling is still a lot slower than with Java 6 (in all modules)
a bug that when you drag a card(/piece) from a deck that it draws a selection box at the same time (and selects the pieces) (in all modules with all decks). This sometimes happened before, but now it happens each time
With the argb build the drawing speed is better, and while dragging the
ghost draw speed is good too. But, there are still many issues, such as:
drawing a selection box, redrawing of the black rectangle is still
slow
initiating a drag, you have to hold a piece for about a second before
the drag ghost draws (in Memoir '44, in modules with few pieces less of
a problem). This makes rapid (small) moves of pieces a pain
drawing is still slower, in No Retreat! (GMT) for example I can see
the map tiles slowly fading in after scrolling
scrolling is still a lot slower than with Java 6 (in all modules)
a bug that when you drag a card(/piece) from a deck that it draws a
selection box at the same time (and selects the pieces) (in all modules
with all decks). This sometimes happened before, but now it happens each
time
It looks like Java 7u45 is too broken to be usable on Macs like yours.
I’m now inclined to wait with updating the app bundle to use Java 7
until Oracle fixes whatever the problem is.
It looks like Java 7u45 is too broken to be usable on Macs like yours.
I’m now inclined to wait with updating the app bundle to use Java 7
until Oracle fixes whatever the problem is.
Apple still supplies Java 6 with 10.9, and VASSAL works on it (as well
as it does). So I think it’s best to stick to Java 6 for now.
There’s one more thing we can try. I’ve made a build for which java2d
will output detailed information about what it’s drawing:
Run this once with Java 6 and once with Java 7, saving the errorLog
between runs. Load the same module on each run and do some things which
cause poor performance with Java 7. Try to do approximately the same
things on each run, and describe what you did.
Just get VASSAL 4 out before Apple ships 10.10 next year .
Drag a card from the draw pile onto the board to the left 3 times
Close game, no save, close module
A potential clue: the Java 6 log has 2625 lines, the Java 7 log of the
same has 41785 lines.
Thanks for that. The main difference I spot is that the Java 7 log is
using the OpenGL rendering path (which should be fast, but it looks like
a lot of copying is happening).
At first I thought, WOW! this is even faster than 3.2.8. But the selection script you wrote launched it in Java 6, so I cheered too soon. When I forced it into Java 7 it was as slow as before, and still lots of OpenGL messages in the log (attached).