JDK-8230007

[Per-Erik Svensson]

Hi,

First of all, sorry if this is not the place but I've been trying to find a
way to comment on a bug that I reported a few days ago, since Kevin
Rushforth has commented on it in a way that makes me believe that the bug
may receive a harder than needed triage and that you (possibly) will spend
unnecessary time looking for a solution. So this is my attempt at reaching
the devs.

Secondly, I think a P4 priority is fine, it's probably not a common bug,
nothing crashes and I've found a workable workaround (see below).

As the report states, this has nothing to do with the use of Robot. We get
this error without using either AWT Robot or JFX Robot. The reason Robot is
used is so that I could send a minimal amount of code showing the problem
without having to make further instructions about resizing, how many pixels
and so on. Just a couple lines of code to force the bug to show on screen.
If you resize manually, one needs a fairly steady hand to see the bug as
more than a flickering. So I wanted the code to show that the skewed
rendering is persistent at certain pixels, not just a flickering that
corrects itself.

You may remove the entire loadWorker-listener and the bug will still be
reproducible always, but then you need to manually resize the JFrame (with
a steady hand to hit the correct pixels and release the mouse button
without moving the mouse away from that position). It's not hard to do
manually, just harder than to show the bug programmatically.

(As an aside: Kevin Rushforth's comment hints at it being more natural to
use AWT Robot in a JFrame. This is true but I needed to wait for the
WebEngine to load the site before resizing the window so it made more sense
to me to use JFX's Robot since I was on the JFX-thread.)

Any way, the bug is reproducible without Robots of any kind so the bug is
either a problem with JFXPanel or JavaFX/Swing/AWT's HiDPI support or more
likely, that the HiDPI support of the different frameworks don't play nice
with each other. The following workaround may give more insight.

If the JFXPanel's setBounds(int,int,int,int) is overriden with code to
"skip" every pixel resize that, when multiplied with the DPI-scaling of the
screen, results in a number that ends with .25 or .75, everything works
without a skewed rendering. This obviously means that the JFXPanel will
sometimes be smaller than it should be and thus not rendering all the way
out to the parent's bounds, but that is a tradeoff I'm willing to make. A
few missed pixels on high resolution monitors isn't as eye jarring as a 45
degree x-shearing of the entire rendering surface.

Here is example code to show how the "skipping" is done:

JFXPanel jfx = new JFXPanel() {
    private int skipPixels(int number, double scale) {
        double scaled = number * scale;
        while((scaled - Math.floor(scaled) == 0.25) || (scaled -
Math.floor(scaled) == 0.75)) {
            number--;
            scaled = number * scale;
        }
        return number;
    }

    @Override
    public void setBounds(int x, int y, int width, int height) {
        double scaleX =
getGraphicsConfiguration().getDefaultTransform().getScaleX();
        double scaleY =
getGraphicsConfiguration().getDefaultTransform().getScaleX();
        int w = skipPixels(width, scaleX);
        int h = skipPixels(height, scaleY);
        super.setBounds(x, y, w, h);
    }
};


Finally, I must say I'm impressed with how you handle bugs from the web
form. Thanks for that!

Best Regards
Per-Erik Svensson