Thus spake bolabola:
Yes, this was also what I initially feared. That this would be hard and
very time consuming to fix.
I think it won’t be trivial, but it’s a problem where all the relevant code
is ours, which means there’s far less uncertainty involved than with, say,
determining how to bundle Java into our DMG. (We got it, but I could not
predict when or even if we would.)
Again, I think it is worth considering just using the
-Dsun.java2d.uiScale=1.0 system property. This should make 3.3.3 work in
exactly the same way as 3.2.17 with regards to scaling. Everything
should work, but with no HDPI support as in 3.2.17 though.
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.
With a couple of hundred of lines, you get amazingly far.
It’s an interesting looking demo. I managed something similar with very
little code a few years ago in C++ using SDL. We have a huge amount of
code which would not have needed to be written if we’d had a different
design model, but I think this also shows that it doesn’t take much to
get halfway there, and that it’s the second half which is far more work.
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.
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”.
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.
I won’t willingly go down that road a second time.
–
J.