uckelman wrote:> Are you sure? Even for people with HiDPI screens? I was under the
> impression that this would make 3.3.0 very small for people with HiDIP
> screens. Am I wrong here? If I've misunderstood the situation, I'd like
> to know.
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).
uckelman wrote:> I have a long list of complaints about Java at this point; after working
> in Java for 15 years, I feel I've come by them honestly. One category of
> these complaints concerns image decoding. Anything you do in JavaFX is
> going to be afflicted by these as well, so far as I can see.
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.
uckelman wrote:> I have put hundreds of hours into investigating and working around image
> decoding bugs in Java over the years, and hardly any of those bugs have
> been fixed during that time. There's one PNG loading bug in Oracle's
> tracker which has had an obviously correct patch sitting there for more
> than a decade now. If you submitted a bug to libpng demonstrating that a
> correct PNG was misdecoded, you might wait a few weeks tops for a release
> that fixed the bug. It's not as though there are only one or two such
> bugs, either. I count workarounds for 13 different image decoding bugs in
> our image loader right now.
> And it's not just problems with unusual but standards-compliant images.
> The JPEG loader _class_ in ImageIO isn't thread-safe. That is not a typo,
> the _class_ is not thread safe. The whole class is not thread safe. You
> literally cannot safely load JPEGS on two different threads
> simultaneously even when each thread has its own JPEG decoder; if you do,
> you risk an unchecked exception being thrown. It's blindingly obvious why,
> too, if you look at the code, and it's shocking that they let it out the
> door in the first place. This bug's been around for ages as well. No joke,
> the sole acknowledgement the bug report got from someone at Oracle was:
> "We don't have plans to fix it".
Looking at the code in the ImageIOImageLoader class in Vassal and all the workarounds you implemented to correctly decode JPEG images, I fully understand your frustration with the ImageIO, and Oracle's unwillingness to fix the issues. It is amazing that you had the patience to go to such lengths to implement workarounds for something that Oracle should have fixed. And I agree, it doesn't reflect well on Sun, that they released an Image IO library that you cannot use in the thread safe manner.
Again though, none of this would not be an issue in JavaFX, due to the completely different implementation. All the complex code in the image and imageop packages for image transforms, tiling and image decoding, which I assume was originally written to overcome limitations in AWT / Swing due to functionality limitations and poor performance. None of this is necessary in JavaFX. You simply load the images, and JavaFX handles all the logic around affine transformations (scaling, rotating, filtering, animations) by pushing the images to the GPU and executing the transforms there.
uckelman wrote:Correct image decoding is vital to us; most of what we do is display
images in various arrangements. It's been infuriating to have to devote
so much time to a problem that exists only because Java neither uses
the standard image loading libraries nor properly maintains its own.
This luckily this is not the case with JavaFX. As you surely know Java (OpenJDK) and JavaFX (OpenJFX) has been open sourced, and has a very vibrant community, allowing for much faster turnaround on fixes, in part because of the new 1/2 release cycle, as well as a very active open source community around the OpenJDK and OpenJFX.
Using JavaFX also has the added advantage, that some parts of the Vassal codebase might be reuseable, and making old module plugins work would be a lot easier. I also think it would be a lot easier to find contributors.
Another of the main pain points with Vassal and Java during the years has been, as I understand it, that Vassal had to work on many different versions Java, due to the lack of control of the runtime environment on the end user machine. This is luckily no longer an issue, due to jlink and the option to package the Java runtime with the application.
uckelman wrote:I won't willingly go down that road a second time.
I hope that this answers at least some of your concerns about using JavaFX.
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.