Thus spake bolabola:
No, I am not 100% sure, but I would think so. If you can provide me we a
build with the system property set, I can test whether it works in
exactly the same way as 3.2.17, (that is no scaling).
I’ve uploaded a set of builds which launch with -Dsun.java2d.uiScale=1.0
set, named svn9292-uiscale, here:
vassalengine.org/~uckelman/tmp/
The image decoding is a completely different implementation in JavaFX,
and doesn’t use or require usage of ImageIO in any way. It is also
thread safe. It supports PNG, BMP, GIF and JPEG images out of the box.
Custom decoding implementations (for SVG for example) can be provided to
JavaFX by implementing custom ImageLoaders, but without the need to
implement complex transform algorithms, as this be done by the JavaFX
core (on the GPU).All decoder implementations are pure java implementations, except for
the JPEG implementation, which uses the latest version of the libjpeg
library.
It sounds like they’re repeating the same mistake made with ImageIO,
namely that they’re not using the standard image libraries that the
entire rest of the software world uses. Nor does leaving out SVG
inspire confidence.
I hope that this answers at least some of your concerns about using
JavaFX.
Thanks for the explanation, but I’m not interested in continuing to use
Java in any form for VASSAL 4. Even if all my concerns regarding images
were satisfied, I still have an overwhelming collection of other reasons
for using somehting else. I don’t see much future in Java at this point,
and I don’t want us tied to it.
If you need to me to test anything related to scaling, please to don’t
hesitate to let me know. I’ll be more than happy to help out with the
testing of Vassal 3.3.0. Zgrose can properly also be helpful in this
regard, as he is also using a HDPI monitor.
Thanks. Give the build above a try. What I’m interested in particular is
if the UI scaling differs from 3.2.17. (If the scaling behavior is the
same as 3.2.17, then we can release 3.3.0 this way and fix HiDPI scaling
for 3.3.1.)
–
J.