[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: JDK-8230007
From:       Thimo von Rauchhaupt <t.rauchhaupt () googlemail ! com>
Date:       2019-08-26 6:46:14
Message-ID: CAKdJvwa2KQZp4a_cbcifqBwy9NdqD8KfhW8_7Bz5yVBVNV_Y7g () mail ! gmail ! com
[Download RAW message or body]

Hi,

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,
Thimo

Per-Erik Svensson <pererik.svensson@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
>
>
[prev in list] [next in list] [prev in thread] [next in thread]