3.1.x problems in linux

[fierman]

Hello,

for a few months now I have been following the new versions of VASSAL, hoping they will work on my machine. To no avail however so far.

machine:
Intel dualcore @ 2GHz , 4 GB of RAM, X3100 Intel gfx (onboard)
Running linux, direct rendering enabled, java version: 1.6.0_07

Problem:
VASSAL stops responding on a lot of modules on loading & displaying the map of the module. Map section shows just a blank screen, in some cases the complete userinterface is not displayed anymore. In all cases the userinterface of VASSAL is hardly responsive, or not at all.
Examples: storm over stalingrad, devil’s cauldron

In a few other cases the map is eventually displayed, but when trying to resize the map the same described problems appear again: the display doesnt show the map anymore, just a blank screen. Scrolling the map does not help.
Example: the mighty endeavor, fallschirmjaeger

In a very few cases the map displays fine, and all is well.
Example: storm over arnhem.

I had the error log open, but no error was given at all. Initial heapsize was set at 512MB at first, to 1024MB later. Max heapsize was gradually set to over 3GB, this all made no difference in performance.
The CPU load was high: xorg showed a constant load of around 70%… java stuck at around 15%

In 3.0 none of these problems exist, all modules load in fine, and the program is always fast and responsive. I even tried out the notorious Case Blue, and that one displayed, zoomed, scrolled and generally performed just as well as the smaller modules.

I hope my description is extensive enough, and I hope this contributes to an even better VASSAL. many thanks to the devvers for this program. I love it!

cheers.

[mkiefte]

I’m going to offer a couple of suggestions here, none of which may be helpful.

First off, don’t keep increasing your Java heep. This will just complicate things. Keep it at 512 MB. That’s more than large enough for almost everything.

The most suspicious thing here is xorg showing 70% CPU time. That’s not normal. Might I suggest that there is something wrong with your video driver? What distro of linux are you running?

• Michael.

2009/6/12 fierman <messages@forums.vassalengine.org (messages@forums.vassalengine.org)>

Hello,

for a few months now I have been following the new versions of VASSAL, hoping they will work on my machine. To no avail however so far.

machine:
Intel dualcore @ 2GHz , 4 GB of RAM, X3100 Intel gfx (onboard)
Running linux, direct rendering enabled, java version: 1.6.0_07

Problem:
VASSAL stops responding on a lot of modules on loading & displaying the map of the module. Map section shows just a blank screen, in some cases the complete userinterface is not displayed anymore. In all cases the userinterface of VASSAL is hardly responsive, or not at all.
Examples: storm over stalingrad, devil’s cauldron

In a few other cases the map is eventually displayed, but when trying to resize the map the same described problems appear again: the display doesnt show the map anymore, just a blank screen. Scrolling the map does not help.
Example: the mighty endeavor, fallschirmjaeger

In a very few cases the map displays fine, and all is well.
Example: storm over arnhem.

I had the error log open, but no error was given at all. Initial heapsize was set at 512MB at first, to 1024MB later. Max heapsize was gradually set to over 3GB, this all made no difference in performance.
The CPU load was high: xorg showed a constant load of around 70%… java stuck at around 15%

In 3.0 none of these problems exist, all modules load in fine, and the program is always fast and responsive. I even tried out the notorious Case Blue, and that one displayed, zoomed, scrolled and generally performed just as well as the smaller modules.

I hope my description is extensive enough, and I hope this contributes to an even better VASSAL. many thanks to the devvers for this program. I love it!

cheers.

Post generated using Mail2Forum (mail2forum.com)

[fierman]

Thanks for your reply.
jvm heap doesnt indeed change anything, whatever value i set it to. would not expect that one to be the culprit anyway,

xorg showing a load of 70% cpu is indeed a bit weird.
I am running ubuntu hardy, with the 2.6.24-23-server kernel provided by the standard repository. xorg uses the intel driver, which supports the chipset in my onboard gfx card (the 965GM) Direct rendering is enabled, and works fine for other applications.

Like you said, I suspect the problem to be somewhere in xorg as well, but since VASSAL 3.0 works without any problems, and since I dont have any other problems with any other software on this machine, It might be likely that the problem is not with my machine per-se.

F.

@mkiefte

I’m going to offer a couple of suggestions here, none of which may be helpful.

First off, don’t keep increasing your Java heep. This will just complicate things. Keep it at 512 MB. That’s more than large enough for almost everything.

The most suspicious thing here is xorg showing 70% CPU time. That’s not normal. Might I suggest that there is something wrong with your video driver? What distro of linux are you running?

• Michael.

2009/6/12 fierman

Hello,

for a few months now I have been following the new versions of VASSAL, hoping they will work on my machine. To no avail however so far.

machine:
Intel dualcore @ 2GHz , 4 GB of RAM, X3100 Intel gfx (onboard)
Running linux, direct rendering enabled, java version: 1.6.0_07

Problem:
VASSAL stops responding on a lot of modules on loading & displaying the map of the module. Map section shows just a blank screen, in some cases the complete userinterface is not displayed anymore. In all cases the userinterface of VASSAL is hardly responsive, or not at all.
Examples: storm over stalingrad, devil’s cauldron

In a few other cases the map is eventually displayed, but when trying to resize the map the same described problems appear again: the display doesnt show the map anymore, just a blank screen. Scrolling the map does not help.
Example: the mighty endeavor, fallschirmjaeger

In a very few cases the map displays fine, and all is well.
Example: storm over arnhem.

I had the error log open, but no error was given at all. Initial heapsize was set at 512MB at first, to 1024MB later. Max heapsize was gradually set to over 3GB, this all made no difference in performance.
The CPU load was high: xorg showed a constant load of around 70%… java stuck at around 15%

In 3.0 none of these problems exist, all modules load in fine, and the program is always fast and responsive. I even tried out the notorious Case Blue, and that one displayed, zoomed, scrolled and generally performed just as well as the smaller modules.

I hope my description is extensive enough, and I hope this contributes to an even better VASSAL. many thanks to the devvers for this program. I love it!

cheers.

Post generated using Mail2Forum (mail2forum.com)

[danjaman]

Do Intel do proprietary drivers for Linux?? If so, get them…

[fierman]

@danjaman

Do Intel do proprietary drivers for Linux?? If so, get them…

they don’t. no need to either.

[mkiefte]

danjaman wrote:

Do Intel do proprietary drivers for Linux?? If so, get them…

they don’t. no need to either.

965GM? Is this on a laptop?

Like you said, I suspect the problem to be somewhere in xorg as well, but since VASSAL 3.0 works without any problems, and since I dont have any other problems with any other software on this machine, It might be likely that the problem is not with my machine per-se.

The graphics have changed a lot since 3.0.

What happens when you disable direct rendering?

• M.

Post generated using Mail2Forum (mail2forum.com)

[uckelman]

Thus spake “danjaman”:

Do Intel do proprietary drivers for Linux?? If so, get them…

Intel does better than that, and provides open-source drivers. Those
drivers are already in xorg.

–
J.

---

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

[danjaman]

Intel does better than that, and provides open-source drivers. Those
drivers are already in xorg.

Then they get the ‘we are excellent award’ for Sat June 13 2009. Got Nvidia myself and have never had any experience with Intel graphics on Linux… only on XP laptops…

I guess the two main GPU manufacturers are too busy hiding tech from each other to go open source, damn this capitalist system and its secretive ways…

The combination of the best technology from both ATI and Nvidia, with Intel open-ness would be the best for all concerned…

[fierman]

I tested some more, on 2 other machines as well, and my conclusion is that we can more or less rule out gfx cards, drivers and direct rendering.
(i tried it on the laptop with direct rendering disabled, the problems as described in my first post persisted)
I used the modules Storm over Stalingrad and Mighty Endeavor to check out behaviour. tried map scrolling, map zooming and moving of units.

machine1:
ubuntu jaunty, 2.6.28-11-generic
matrox g400 card (with a whopping 32MB , using mga driver, direct rendering enabled
1GB memory, athlon @~2300 MHz

Vassal 3.1.6 performed nicely; no abnormal CPU load on Xorg, on loadup of the modules there were a few hickups on screen update which I didnt notice in 3.0.x , with a CPU load of around 60% on java occassionally, but nothing abnormal.

machine 2:
ubuntu hardy, 2.6.24-18-server
nvidia 64MB card, using nvidia driver. direct rendering enabled
1GB memory, athlon @~2200 MHz

Vassal 3.1.6 gave more or less the same problems as described in my first post. CPU load was a bit lower on Xorg though, around 50%. Eventually the modules would load, but using them is out of the question. Screen scrolling is impossible without having to wait for over a minute for the screen to build up again. This is more or less similar as the behaviour on my laptop.

Careful conclusion: I figure that the 2.6.24 kernel does not like vassal 3.1.*

I will build a new kernel for my laptop when i have time, see how it behaves on that.

thanks for the replies so far!

[uckelman]

Thus spake “fierman”:

Carefuk conclusion: I figure that the 2.6.24 kernel does not like vassal 3.1.

I developed the graphics loading code in 3.1 on a laptop with internals
similar to yours—same Intel graphics chipset, a Core 2 Duo, etc.—
and also on Linux (Fedora 9 and 10), and never saw anything like what
you’re describing. I’m sure I must have used a 2.6.24 kernel at some point,
though right now I’m using 2.6.27.

I can’t think of any reason why you’d be seeing what you’re seeing, so if
you can track down what exacty the problem is, that would at least be
enlightening.

The graphics loading code in 3.1, so far as I’ve been able to verify, works
exactly the way it’s supposed to, assuming that the systems it relies on are
themselves working properly. It seems like the code I wrote has a tendancy
to reveal bugs elsewhere, for what reasons a I don’t understand, as there’s
nothing particularly weird about it.

Any further insight you can provide about what’s going wrong would be
appreciated, as I’ve never been able to replicate for myself any of the
problems of this sort that people have reported.

–
J.

---

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

[mkiefte]

I’m also running various versions of Ubuntu on all my machines and have yet to notice anything out of the ordinary. I also doubt very strongly that it has anything to do with the kernel, although I cannot attest to that as it appears I’m running 2.6.27 everywhere.

I’ve also got an NVIDIA GPU GeForce 7600 GT and am using the proprietary drivers (version 180). I did have issues with version 177 and wine, but the most recent version has cleared that up. Never had a problem with VASSAL, though.

I ought to warn you that the most efficient setting in the Preferences dialog are not really obvious. I’ve used “Prefer memory-mapped files for large images” even when heap settings are relatively high. Sometimes that just works faster for large maps whether you have the available memory or not. I suspect that has to do with piecemeal image processing versus large-scale processing. I would also toggle “high-quality scaling”. That interacts with Xorg in difficult-to-predict ways.

Let me know whether either of these suggestions help.

• M.

2009/6/13 Joel Uckelman <uckelman@nomic.net (uckelman@nomic.net)>

Thus spake “fierman”:

Carefuk conclusion: I figure that the 2.6.24 kernel does not like vassal 3.1.

I developed the graphics loading code in 3.1 on a laptop with internals
similar to yours—same Intel graphics chipset, a Core 2 Duo, etc.—
and also on Linux (Fedora 9 and 10), and never saw anything like what
you’re describing. I’m sure I must have used a 2.6.24 kernel at some point,
though right now I’m using 2.6.27.

I can’t think of any reason why you’d be seeing what you’re seeing, so if
you can track down what exacty the problem is, that would at least be
enlightening.

The graphics loading code in 3.1, so far as I’ve been able to verify, works
exactly the way it’s supposed to, assuming that the systems it relies on are
themselves working properly. It seems like the code I wrote has a tendancy
to reveal bugs elsewhere, for what reasons a I don’t understand, as there’s
nothing particularly weird about it.

Any further insight you can provide about what’s going wrong would be
appreciated, as I’ve never been able to replicate for myself any of the
problems of this sort that people have reported.

–
J.

Post generated using Mail2Forum (mail2forum.com)

[fierman]

@uckelman

I can’t think of any reason why you’d be seeing what you’re seeing, so if
you can track down what exacty the problem is, that would at least be
enlightening.

[snip]

Any further insight you can provide about what’s going wrong would be
appreciated, as I’ve never been able to replicate for myself any of the
problems of this sort that people have reported.

–
J.

I ran vassal with java error logging enabled: nothing peculiar there.
I can’t think of any other further ways to investigate apart from trying with another kernel… I’m rather clueless codingwise

If you have any tips that could help me getting logs that could be of any use to you, please tell me. I would be most happy to try them out.

would like to stress that for me personal it is not a real big issue: 3.0 works fine here for the modules that i am interested in, so best regard my report as a contribution to the community.

F.

[fierman]

@mkiefte

I’m also running various versions of Ubuntu on all my machines and have yet to notice anything out of the ordinary. I also doubt very strongly that it has anything to do with the kernel, although I cannot attest to that as it appears I’m running 2.6.27 everywhere.

I’ve also got an NVIDIA GPU GeForce 7600 GT and am using the proprietary drivers (version 180). I did have issues with version 177 and wine, but the most recent version has cleared that up. Never had a problem with VASSAL, though.

I ought to warn you that the most efficient setting in the Preferences dialog are not really obvious. I’ve used “Prefer memory-mapped files for large images” even when heap settings are relatively high. Sometimes that just works faster for large maps whether you have the available memory or not. I suspect that has to do with piecemeal image processing versus large-scale processing. I would also toggle “high-quality scaling”. That interacts with Xorg in difficult-to-predict ways.

Let me know whether either of these suggestions help.

• M.

Thanks for the input!

Tried again with all kinds of combinations in the options, none of them made any noticable difference. Since my machine has 4GB of memory I wouldn’t really expect the memory mapping option to make any real impact though. ‘high quality scaling’ turned off didn’t make any difference either. Even with the map scaled at 100%, just scrolling the map made cpu load go up to 70% on xorg, and made Vassal almost completely unresposive.

F.

[mkiefte]

Thanks for the input!

Tried again with all kinds of combinations in the options, none of them made any noticable difference. Since my machine has 4GB of memory I wouldn’t really expect the memory mapping option to make any real impact though. ‘high quality scaling’ turned off didn’t make any difference either. Even with the map scaled at 100%, just scrolling the map made cpu load go up to 70% on xorg, and made Vassal almost completely unresposive.

F.

I apologise for the silence on this issue, but it’s pretty safe to say that we’re stuck. This is one of those problems where you really wish you could be there to see exactly what’s going on.

It’s pretty clear that there’s some funny interaction going on between X and Java. I’ve never seen this problem before. One more question though: Do you have Compiz running on your desktop? I don’t, but I know Joel was trying to get it to work and it interacted with Java rendering in undesirable ways. I believe that was related to 3d rendering, however. Just a thought. If you have it on, turn it off.

• M.

Post generated using Mail2Forum (mail2forum.com)

[uckelman]

Thus spake Michael Kiefte:

I apologise for the silence on this issue, but it’s pretty safe to say that
we’re stuck. This is one of those problems where you really wish you could
be there to see exactly what’s going on.

It’s pretty clear that there’s some funny interaction going on between X and
Java. I’ve never seen this problem before. One more question though: Do
you have Compiz running on your desktop? I don’t, but I know Joel was trying
to get it to work and it interacted with Java rendering in undesirable
ways. I believe that was related to 3d rendering, however. Just a
thought. If you have it on, turn it off.

I should mention that I haven’t had that problem with Compiz for quite
a while now—but it’s worth a try. Ubuntu lags Fedora a bit in versions,
so it could be that someone using Ubuntu now is having problems like I
had on Fedora some months ago.

–
J.

---

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

[uckelman]

Followup: The problem here could well be either with the kernel or the X server. In the past few weeks, there have been both kernel updates and X server updates (in Fedora Linux) which break things on Intel graphics chipsets. My prediction is that there is some kernel-X server combination where you won’t have this problem.