Test builds for 3.3.0

[uckelman]

Thus spake bolabola:
>
> I have added a couple of screenshots so you can see the issue.
>
> As you can see, when I set my operating system scaling to 100%,
> everything looks fine, but on 150% scaling all images becomes blurred.

I must not be grasping the problem here. It seems obvious to me if
you upscale the UI by 50%, it will become blurry. Why is that a bug
in VASSAL rather than an expected consequence of upscaling?

--
J.

[bolabola]

Thus spake bolabola:
>
> I have added a couple of screenshots so you can see the issue.
>
> As you can see, when I set my operating system scaling to 100%,
> everything looks fine, but on 150% scaling all images becomes blurred.

I must not be grasping the problem here. It seems obvious to me if
you upscale the UI by 50%, it will become blurry. Why is that a bug
in VASSAL rather than an expected consequence of upscaling?

--
J.

It is not a bug in Vassal, it is a bug in the JDK image rendering engine. In JDK 9 HDPI monitor support was added. This scales the UI in the Java application according to the scaling settings in the operating system. This works fine for UI elements (button, labels, text), but causes issues with Image rendering.

No matter which zoom level I use in Vassal when having the scaling in the operating system set to anything other than 100%, images (map, counters, UI icons) gets blurred and jagged, because the Image / BufferedImage has a bug. Images are run through the image scaling transformation twice (once by the JDK, and once by the operation system (D3D), resulting in a blurred image).

Note that if I set my operating system scaling to 100%, and zoom to 150% in Vassal, maps and images still look very smooth.

As I wrote in my previous post, the issue is known to the JDK developers: https://bugs.openjdk.java.net/browse/JD ... 22image%22

Most users (except users running on HDPI laptops) will have the operating system scaling set to 100%, and will not experience the issue at all.

I think the fix is relatively easy. If HDPI support is disabled by the system property (-Dsun.java2d.uiScale=1), Vassal will work exactly as it did on HDPI screen as it did before the upgrade to JDK 9.

I hope this makes it a bit clearer. If not, please let me know.

/Bo

[ClaudioC]

Thus spake ClaudioC:
> Joel, I am now trying to play all my ongoing games with the latest
> build.
> Yesterday I opened the log of a Vietnam game and got the following
> module errors.

We've changed nothing in our own code which parses dates. This is
probably due to a change in Java between versions 6 and 13. I'll need
a vlog file which triggers the error in order to troubleshoot the
problem.

--
J.

Hello Joel, file is too big to attach. (forum limits me to 256kB). Can you send me your email so that I can send you the file? Or tell me how to proceed.
Kr
Claudio

[ClaudioC]

Hello Joel,
I tried to make a change in a game module, and saved it to a new vmod file.
When I tried to open the module with 9287, I got this error

"The module you are trying to use (E:\Vassal\TLD\Tld-0.1.9.019.vmod) was created with VASSAL 3.3.0-svn9287. This version of VASSAL (3.3.0-svn9287) cannot edit or play modules which are that new."

Kr
Claudio

"

[uckelman]

Thus spake ClaudioC:
>
> Hello Joel, file is too big to attach. (forum limits me to 256kB). Can
> you send me your email so that I can send you the file? Or tell me how
> to proceed.
> Kr
> Claudio

There's a little icon with an envelope and an @ symbol under my avatar
to the right of my posts. That has a link with my email address. (Everyone
has one of those.)

--
J.

[zgrose]

Thus spake ClaudioC:
There's a little icon with an envelope and an @ symbol under my avatar
to the right of my posts. That has a link with my email address. (Everyone
has one of those.)

I don't see that icon on anyone:

Annotation 2019-11-04 090051.png (116.11 KiB) Viewed 2233 times

[uckelman]

Thus spake zgrose via messages:
>
> "uckelman" wrote:
> > Thus spake ClaudioC:
> > There's a little icon with an envelope and an @ symbol under my avatar
> > to the right of my posts. That has a link with my email address.
> > (Everyone
> > has one of those.)
> >
>
> I don't see that icon on anyone:

Weird. My email address is uckelman@nomic.net.

--
J.

[uckelman]

Joel, I am now trying to play all my ongoing games with the latest build.
Yesterday I opened the log of a Vietnam game and got the following module errors.

- VG Vietnam version 4.3.4
- Loading Claudio_vs_Petri_Vietnam_01236.vlog ...
- Bad Data in Module: Illegal date format 7/6/19 8:15 PM

Thanks for sending me the vlog. The problem is that a very long time ago, someone unwisely set the internal date format for logs to the default date format that Java provided for the US locale, and the default changed sometime between the version of Java you're using for 3.2.17 and the version of Java we bundle with the 3.3.0 test builds. I've fixed the problem by explicitly specifying the date format so that it can't be changed out from under us again.

Try the svn9290 build I just uploaded.

[ClaudioC]

Joel, I am now trying to play all my ongoing games with the latest build.
Yesterday I opened the log of a Vietnam game and got the following module errors.

- VG Vietnam version 4.3.4
- Loading Claudio_vs_Petri_Vietnam_01236.vlog ...
- Bad Data in Module: Illegal date format 7/6/19 8:15 PM

Thanks for sending me the vlog. The problem is that a very long time ago, someone unwisely set the internal date format for logs to the default date format that Java provided for the US locale, and the default changed sometime between the version of Java you're using for 3.2.17 and the version of Java we bundle with the 3.3.0 test builds. I've fixed the problem by explicitly specifying the date format so that it can't be changed out from under us again.

Try the svn9290 build I just uploaded.

Hello Joel,
It works correctly now. Thank you.
Claudio

[uckelman]

Hello Joel,
It works correctly now. Thank you.
Claudio

Thank you for pointing out the problem and supplying a test case for me.

[uckelman]

It is not a bug in Vassal, it is a bug in the JDK image rendering engine. In JDK 9 HDPI monitor support was added. This scales the UI in the Java application according to the scaling settings in the operating system. This works fine for UI elements (button, labels, text), but causes issues with Image rendering.

I understand what's happening now. Since Java 9, the paint() member function of Swing UI components gets called with a Graphics2D that has an AffineTransform set to the scale factor that's being used for your desktop---but the getWidth() and getHeight() member functions still return unscaled dimensions. So, if you have a component which is 800x600 in terms of user pixels but the OS has a scale factor of 200%, then you have 1600x1200 real pixels on which to paint. If you go ahead and run paint() with the AffineTransform you're handed with the Graphics2D, you will paint at 800x600 but every user pixel you paint will get blown up into four physical pixels on the screen (and look like crap).

But, this only happens with (1) components where you've implemented paint() yourself, and (2) components which paint Images. The Swing components which paint text and other UI widgets are smart enough to spot that they're being scaled, undo the scaling, and paint at full physical size. This is why in your screenshots, the text, button edges, scroll bars, etc. look sharp (well, as sharp as Java UI elements ever look) but the icons and map look upscaled and blurry.

The solution is to do the same thing for custom components as Swing components do for themselves. It turns out that this isn't so difficult to do for the map, so I made a test build for you to try, so we can judge the feasibility of doing this for the remaining components which draw images. The test builds are, here, labeled "hidpitest":

http://www.vassalengine.org/~uckelman/tmp/

If this works for you like it did for me, you should get a smoothly scaled map no matter what your desktop scale factor is. Anything else which was poorly scaled before, such as icons, should still be that way, as I haven't attempted to modify drawing of anything but the map yet.

I'm interested to know how well this works for you.

[bolabola]

It is not a bug in Vassal, it is a bug in the JDK image rendering engine. In JDK 9 HDPI monitor support was added. This scales the UI in the Java application according to the scaling settings in the operating system. This works fine for UI elements (button, labels, text), but causes issues with Image rendering.

I understand what's happening now. Since Java 9, the paint() member function of Swing UI components gets called with a Graphics2D that has an AffineTransform set to the scale factor that's being used for your desktop---but the getWidth() and getHeight() member functions still return unscaled dimensions. So, if you have a component which is 800x600 in terms of user pixels but the OS has a scale factor of 200%, then you have 1600x1200 real pixels on which to paint. If you go ahead and run paint() with the AffineTransform you're handed with the Graphics2D, you will paint at 800x600 but every user pixel you paint will get blown up into four physical pixels on the screen (and look like crap).

But, this only happens with (1) components where you've implemented paint() yourself, and (2) components which paint Images. The Swing components which paint text and other UI widgets are smart enough to spot that they're being scaled, undo the scaling, and paint at full physical size. This is why in your screenshots, the text, button edges, scroll bars, etc. look sharp (well, as sharp as Java UI elements ever look) but the icons and map look upscaled and blurry.

The solution is to do the same thing for custom components as Swing components do for themselves. It turns out that this isn't so difficult to do for the map, so I made a test build for you to try, so we can judge the feasibility of doing this for the remaining components which draw images. The test builds are, here, labeled "hidpitest":

http://www.vassalengine.org/~uckelman/tmp/

If this works for you like it did for me, you should get a smoothly scaled map no matter what your desktop scale factor is. Anything else which was poorly scaled before, such as icons, should still be that way, as I haven't attempted to modify drawing of anything but the map yet.

I'm interested to know how well this works for you.

Hi Joel

I have tested your hdpi version. The map is now rendered smoothly as expected, but only some of the map. I am by no means an expert, but it seems that the change introduces a viewport issue. Only 1/4 of the map is rendered. If I drag the scollbars, a different part of the map is rendered, but on 1/4 it seems. If I drag a selection square on the map, the same part of the map is rendered inside the dragged square.

I'll email you a screendump, so you can get a better idea of what it looks like.

[bolabola]

It is not a bug in Vassal, it is a bug in the JDK image rendering engine. In JDK 9 HDPI monitor support was added. This scales the UI in the Java application according to the scaling settings in the operating system. This works fine for UI elements (button, labels, text), but causes issues with Image rendering.

I understand what's happening now. Since Java 9, the paint() member function of Swing UI components gets called with a Graphics2D that has an AffineTransform set to the scale factor that's being used for your desktop---but the getWidth() and getHeight() member functions still return unscaled dimensions. So, if you have a component which is 800x600 in terms of user pixels but the OS has a scale factor of 200%, then you have 1600x1200 real pixels on which to paint. If you go ahead and run paint() with the AffineTransform you're handed with the Graphics2D, you will paint at 800x600 but every user pixel you paint will get blown up into four physical pixels on the screen (and look like crap).

But, this only happens with (1) components where you've implemented paint() yourself, and (2) components which paint Images. The Swing components which paint text and other UI widgets are smart enough to spot that they're being scaled, undo the scaling, and paint at full physical size. This is why in your screenshots, the text, button edges, scroll bars, etc. look sharp (well, as sharp as Java UI elements ever look) but the icons and map look upscaled and blurry.

The solution is to do the same thing for custom components as Swing components do for themselves. It turns out that this isn't so difficult to do for the map, so I made a test build for you to try, so we can judge the feasibility of doing this for the remaining components which draw images. The test builds are, here, labeled "hidpitest":

http://www.vassalengine.org/~uckelman/tmp/

If this works for you like it did for me, you should get a smoothly scaled map no matter what your desktop scale factor is. Anything else which was poorly scaled before, such as icons, should still be that way, as I haven't attempted to modify drawing of anything but the map yet.

I'm interested to know how well this works for you.

Hi Joel

I have tested your hdpi version. The map is now rendered smoothly as expected, but only some of the map. I am by no means an expert, but it seems that the change introduces a viewport issue. Only 1/4 of the map is rendered. If I drag the scollbars, a different part of the map is rendered, but on 1/4 it seems. If I drag a selection square on the map, the same part of the map is rendered inside the dragged square.

I'll email you a screendump, so you can get a better idea of what it looks like.

I have done a bit more testing. When I set my desktop scale to 100%, the map initially renders smoothly, but if I drag a selection square, the rendering artifact persists. Also, when using the scollbars, weird rendering artifacts appear.

I hope this is helpful.

Let me know if there is anything I can do to help, or if you need more tests.

I can also test a version with the system property -Dsun.java2d.uiScale=1.0 set, if you want. This might be a solution for now, if adding HDPI support to Vassal turns out to be a big task. Then possibly HDPI can be added to Vassal 3.3.1 as a feature.

/Bo

[ClaudioC]

It is not a bug in Vassal, it is a bug in the JDK image rendering engine. In JDK 9 HDPI monitor support was added. This scales the UI in the Java application according to the scaling settings in the operating system. This works fine for UI elements (button, labels, text), but causes issues with Image rendering.

I understand what's happening now. Since Java 9, the paint() member function of Swing UI components gets called with a Graphics2D that has an AffineTransform set to the scale factor that's being used for your desktop---but the getWidth() and getHeight() member functions still return unscaled dimensions. So, if you have a component which is 800x600 in terms of user pixels but the OS has a scale factor of 200%, then you have 1600x1200 real pixels on which to paint. If you go ahead and run paint() with the AffineTransform you're handed with the Graphics2D, you will paint at 800x600 but every user pixel you paint will get blown up into four physical pixels on the screen (and look like crap).

But, this only happens with (1) components where you've implemented paint() yourself, and (2) components which paint Images. The Swing components which paint text and other UI widgets are smart enough to spot that they're being scaled, undo the scaling, and paint at full physical size. This is why in your screenshots, the text, button edges, scroll bars, etc. look sharp (well, as sharp as Java UI elements ever look) but the icons and map look upscaled and blurry.

The solution is to do the same thing for custom components as Swing components do for themselves. It turns out that this isn't so difficult to do for the map, so I made a test build for you to try, so we can judge the feasibility of doing this for the remaining components which draw images. The test builds are, here, labeled "hidpitest":

http://www.vassalengine.org/~uckelman/tmp/

If this works for you like it did for me, you should get a smoothly scaled map no matter what your desktop scale factor is. Anything else which was poorly scaled before, such as icons, should still be that way, as I haven't attempted to modify drawing of anything but the map yet.

I'm interested to know how well this works for you.

Hello Joel,
The map paints correctly whatever the vassal zoom + windows zoom I select. So I suppose it confirms what you say. Note that onthe flipside the map drawing seems to behave very strangely. If I scroll down to see the 'south" of the map (arrow downs or elevator bar down) the map picture does not go up, instead a white area scrolls down.

If you need more infos on this I will have to record a short video.
Bye

[uckelman]

There's a simple explanation for the odd map painting: I adjusted the scaling of the map, but missed adjusting the scaling of the visible rectangle, which was computed just above where I was working.

Try the "hidpitest2" build, from the same location.