Test builds for 3.3.0

svn9292 is horrible on my screen. 3.2.17 and svn9291 much better. Hard to tell in isolation but hard for me to resample the image at the moment. In 3.2.17 and svn9291, the two module lines are as big as the GitHub icon.

[attachment=1]Annotation 2019-11-14 161318.png[/attachment]

[attachment=0]Annotation 2019-11-14 162045.png[/attachment]

Wow, that is awful. I was worried that svn9292-uiscale would be very small, not upscaled. What version of Windows is that you’re using?

Windows 10 Pro, v 1903
build 18362.476

Ok, I am sorry you feel that way about Java. Seems there is no point in discussing it further.

I have tested the latest version you provided with the ui scale system property set, and compared it to version 3.1.17. It works in exactly the same way as 3.1.17 and none of the rendering artifacts are present in this version.

Seems to me that this a possible way forward with regards to a 3.3.0 release.

Thus spake bolabola:

I have tested the latest version you provided with the ui scale system
property set, and compared it to version 3.1.17. It works in exactly the
same way as 3.1.17 and none of the rendering artifacts are present in
this version.

What do you make of the rendering issue zgrose posted about earlier today?

–
J.

I have retested both versions just make I didn’t miss anything. Both versions render the same on my 4K screen, and I am also running Windows 10. Both versions render relative small, because neither scale to desktop settings.

I thought that it might be something with the window title rendering, due to AWT using native windows, but that doesn’t seems to be the case. I can’t discern any difference between the to versions.

Seems that zgrose gets HDPI scaling on his 3.2.17 version, which I simply don’t understand.

I bit surprised myself because I remember VASSAL being small on my son’s computer before. But things do constantly change.

[attachment=0]Annotation 2019-11-16 093905.png[/attachment]

[quote=“zgrose”]
I bit surprised myself because I remember VASSAL being small on my son’s computer before. But things do constantly change.

Ok, I think I might have an explanation for what is going on.

When I run 3.2.17, and look at the error log, I get:

2019-11-16 18:20:17,983 [0-main] INFO VASSAL.launch.StartUp - Starting
2019-11-16 18:20:17,984 [0-main] INFO VASSAL.launch.StartUp - OS Windows 8 6.2
2019-11-16 18:20:17,984 [0-main] INFO VASSAL.launch.StartUp - Java version 1.6.0_45
2019-11-16 18:20:17,985 [0-main] INFO VASSAL.launch.StartUp - VASSAL version 3.2.17
2019-11-16 18:20:18,010 [0-AWT-EventQueue-0] INFO VASSAL.launch.ModuleManager - Manager

Seems that I am running Vassal with Java 1.6, which I didn’t even know I had installed.

When running Vassal 3.3.0 I get,

2019-11-16 18:21:38,360 [0-main] INFO VASSAL.launch.StartUp - Starting
2019-11-16 18:21:38,363 [0-main] INFO VASSAL.launch.StartUp - OS Windows 10 10.0
2019-11-16 18:21:38,363 [0-main] INFO VASSAL.launch.StartUp - Java version 13
2019-11-16 18:21:38,363 [0-main] INFO VASSAL.launch.StartUp - VASSAL version 3.3.0-svn9292
2019-11-16 18:21:38,433 [0-AWT-EventQueue-0] INFO VASSAL.launch.ModuleManager - Manager

which makes sense.

Turns out that Java 1.8 actually had some, but flawed, HDPI support. See https://bugs.openjdk.java.net/browse/JDK-8180815. If you look at Pardeep Sharma last comment, it all makes sense.

I think the reason your sons version might have looked small is most likely that he has been running an older version of Java, properly Java 6 or 7.

So apparently Java 8 has some HDPI support, though not perfect (blurred fonts), that doesn’t affect Vassals rendering of images.

I’ll try and fix my local setup to force Vassal 3.2.17 to run against Java 8 and see if I get the same result as you.

I have tried installing a Java 8:

2019-11-16 18:38:43,641 [0-main] INFO VASSAL.launch.StartUp - Starting
2019-11-16 18:38:43,641 [0-main] INFO VASSAL.launch.StartUp - OS Windows 10 10.0
2019-11-16 18:38:43,641 [0-main] INFO VASSAL.launch.StartUp - Java version 1.8.0_231
2019-11-16 18:38:43,641 [0-main] INFO VASSAL.launch.StartUp - VASSAL version 3.2.17

I know I get the same result as you, zgrose. 3.2.17 is now scaled, but with somewhat (not to bad) blurred texts.

So unfortunately it seems that with this in mind, using the -Dsun.java2d.uiScale=1.0 system property in Vassal 3.3.0 would be a regression for users who has been running Vassal on Java 8.

I only just found out about 3.3.0, I am testing on macOS. It feels nice and responsive.

2020-01-08 09:44:43,581 [0-main] INFO VASSAL.launch.StartUp - Starting 2020-01-08 09:44:43,586 [0-main] INFO VASSAL.launch.StartUp - OS Mac OS X 10.15.2 2020-01-08 09:44:43,586 [0-main] INFO VASSAL.launch.StartUp - Java version 13.0.1 2020-01-08 09:44:43,586 [0-main] INFO VASSAL.launch.StartUp - VASSAL version 3.3.0-svn9291

I have modules registered in the Module Manager that are on an external volume (disk), when opening 3.3 it doesn’t have file system permissions to read these files, which means they get erased from the Module Manager – this is a Catalina problem. It would be great if the Module Manager would ask the user for permission to the file system when reading the V_Global and encountering this error, instead of assuming the files are gone and throwing all the entries away. VASSAL pops up a permission dialog if you add a new module from this volume, after which it gets access. But the next time VASSAL launches it throws out all these modules again with not permitted.

java.io.FileNotFoundException: /Users/myuser/Downloads/Normandy_ver094.vmod (Operation not permitted) at java.base/java.io.RandomAccessFile.open0(Native Method) at java.base/java.io.RandomAccessFile.open(Unknown Source) at java.base/java.io.RandomAccessFile.<init>(Unknown Source) at java.base/java.io.RandomAccessFile.<init>(Unknown Source) at java.base/java.util.zip.ZipFile$Source.<init>(Unknown Source) at java.base/java.util.zip.ZipFile$Source.get(Unknown Source) at java.base/java.util.zip.ZipFile$CleanableResource.<init>(Unknown Source) at java.base/java.util.zip.ZipFile.<init>(Unknown Source) at java.base/java.util.zip.ZipFile.<init>(Unknown Source) at java.base/java.util.zip.ZipFile.<init>(Unknown Source) at VASSAL.build.module.metadata.MetaDataFactory.buildMetaData(MetaDataFactory.java:62) at VASSAL.launch.ModuleManagerWindow$ModuleInfo.loadMetaData(ModuleManagerWindow.java:1231) at VASSAL.launch.ModuleManagerWindow$ModuleInfo.<init>(ModuleManagerWindow.java:1259) at VASSAL.launch.ModuleManagerWindow.buildTree(ModuleManagerWindow.java:481) at VASSAL.launch.ModuleManagerWindow.<init>(ModuleManagerWindow.java:376) at VASSAL.launch.ModuleManagerWindow.<clinit>(ModuleManagerWindow.java:178) at VASSAL.launch.ModuleManager.launch(ModuleManager.java:455) at VASSAL.launch.ModuleManager$2.run(ModuleManager.java:342) at java.desktop/java.awt.event.InvocationEvent.dispatch(Unknown Source) at java.desktop/java.awt.EventQueue.dispatchEventImpl(Unknown Source) at java.desktop/java.awt.EventQueue$4.run(Unknown Source) at java.desktop/java.awt.EventQueue$4.run(Unknown Source) at java.base/java.security.AccessController.doPrivileged(Unknown Source) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source) at java.desktop/java.awt.EventQueue.dispatchEvent(Unknown Source) at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source) at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source) at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) at java.desktop/java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.desktop/java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.desktop/java.awt.EventDispatchThread.run(Unknown Source) 2020-01-08 09:44:44,914 [0-AWT-EventQueue-0] INFO VASSAL.launch.ModuleManagerWindow - Module /Users/myuser/Downloads/Normandy_ver094.vmod not found - Removed.

VASSAL asks for permission to access the Remote Volume after which the module loads, but then on the next launch the Module Manager again doesn’t have the permissions. I feel like this worked before I tried to fiddle with it for the screenshots, but now I can’t get it work.

If permission is not granted or withdrawn later VASSAL fails silently, it’ll just close the module or get stuck on the tile loader dialog.

Unarchiver asks for access before extracting a zip file after which it will work for this location forever:

VASSAL Files and Folders permission:

When I drag a card from the Deck it still also creates a selection rectangle as well (which also selects all cards in the Deck). This bug already existed previously, but has not been fixed in 3.3.

I added a module from a new location. VASSAL asked for permission to access that location. And then VASSAL worked again like I thought it did before. It saves the Module Manager list, and has access to the modules.

When I manually restore the RecentModules in V_Global then it somehow changes the signature of VASSAL and it launches it in a new sandbox. Hands Off thinks it’s a new app, and it lost file system access again. It doesn’t re-ask for access, so it still has it, but Module Manager says it doesn’t when checking the files.

This makes it even more important that the Module Manager doesn’t reset the list as the only way to restore it is by manually one-by-one re-adding the modules you had.

Once the permissions are messed up for Module Manager they are messed up. Also for 3.2.17.

Thus spake bdgza:

[This message has been edited.]

I added a module from a new location. VASSAL asked for permission to
access that location. And then VASSAL worked again like I thought it did
before. It saves the Module Manager list, and has access to the modules.

When I manually restore the RecentModules in V_Global then it somehow
changes the signature of VASSAL and it launches it in a new sandbox.
Hands Off thinks it’s a new app, and it lost file system access again.
It doesn’t re-ask for access, so it still has it, but Module Manager
says it doesn’t when checking the files.

This makes it even more important that the Module Manager doesn’t reset
the list as the only way to restore it is by manually one-by-one
re-adding the modules you had.

Once the permissions are messed up for Module Manager they are messed
up. Also for 3.2.17.

So… what you you suggest as a solution?

–
J.

It would detect a difference between “operation not permitted” and “file is not there”, and maybe make an assumption that the former on Mac means a permissions problem due to Catalina. The file should then not be removed from the Module Manager, but can be re-read (to ask the user for Permission to access), or this is retried when you try to launch the module (as if you added it). As long as you don’t lose your entire Module Manager list of modules each time there is a minor issue, and the user can rectify it, perhaps with a manual action, that would be less bad.

The biggest problem I have with VASSAL at the moment is the losing of sync in the Memoir '44 module. When moving pieces in a live internet game the sync is lost and it’s not seen on the other side. This happens constantly, not consistently, but in every game at least once. I haven’t been able to track down anything in my VSAV game files that could be causing this. I haven’t seen any errors in the log. Playing back a vlog doesn’t provide any useful clues, it just loses sync. So far I don’t know if it’s something I do to my VSAV files that I can’t figure out, a problem with my module I can’t figure out (too much in it?), or a bug in VASSAL. I have been trying to find the problem by myself, but I am stumped.

I am playing now a VASSAL 3.3 vs 3.2.17 game and it happened. I want to try to see if it happens with 3.3 vs 3.3.

Is the only change to 3.3.0 a Java platform update? Or, are there other feature additions/changes in the pipeline?

Thus spake eljayplay:

Is the only change to 3.3.0 a Java platform update? Or, are there other
feature additions/changes in the pipeline?

Yes, that’s all. Upgrading to a current version of Java fixes some
problems people are having presently, and that should keep VASSAL usable
while we work on V4.

–
J.

I might have fixed the remaining issue with HDPI support just now. Test builds will follow later today.

Found another snag. Maybe no test builds for a few more days.

Map, Board, and StackMetrics are adjusted for HDPI support now. Still to go are GlobalMap, MenuDisplayer, PieceMover, and CounterDetailViewer.

CounterDetailViewer is adjusted now.