Re: [9] Review request for 8162350 RepaintManager shifts repainted region when the floating point UI scale is used

Hi Alexandr, Is the fully scaling code noticeably slower than the regular code? Is there a reason to test and only use it conditionally? It shouldn't be a lot of overhead considering everything else that goes on during a repaint. Some of the set/unset of attributes could also be optimized

Re: [9] Review request for 8162350 RepaintManager shifts repainted region when the floating point UI scale is used

Hi, Alexandr. Can you please provide some standalone small example, which emulates this artifacts via java2d API. (The pattern which we use in RepainManager). It will help to understand the problem. On 06.10.16 20:07, Alexandr Scherbatiy wrote: Hello, Could you review the fix: bug:

[9] Review request for 8162350 RepaintManager shifts repainted region when the floating point UI scale is used

Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8162350 webrev: http://cr.openjdk.java.net/~alexsch/8162350/webrev.00 The fix uses the solution suggest by Jim in the email: http://mail.openjdk.java.net/pipermail/2d-dev/2016-October/007737.html To draw to

[9] Review request for 8164321: Crash of SwingNode with GTK LaF

Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8164321 webrev: http://cr.openjdk.java.net/~ssadetsky/8164321/webrev.00/ The issue is caused by concurrent XLib access form FX and AWT toolkit threads in case of GTK3. To fix the issue wrapping by