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 <[email protected]> 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 > >
