uckelman wrote: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.
uckelman wrote: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.
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.)
ClaudioC wrote: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
uckelman wrote:ClaudioC wrote: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 wrote:Hello Joel,
It works correctly now. Thank you.
Claudio
bolabola wrote: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.
uckelman wrote:bolabola wrote: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 wrote:uckelman wrote:bolabola wrote: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.
uckelman wrote:bolabola wrote: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.
Users browsing this forum: No registered users and 1 guest