Thimo von Rauchhaupt t.rauchhaupt at googlemail.com
Mon Aug 26 06:46:14 UTC 2019


I'm quite in a rush and not in the office for a time, so I cannot analyze
or write more.
It seems quite the same problem we have already filed under
https://bugs.openjdk.java.net/browse/JDK-8220484 .

Best regards,

Per-Erik Svensson <pererik.svensson at gmail.com> schrieb am Fr., 23. Aug.
2019, 10:52:

> 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

More information about the openjfx-dev mailing list