> 24 февр. 2017 г., в 3:19, Sergey Bylokhov <sergey.bylok...@oracle.com> > написал(а): > > Looks fine. > > I suggest to create a separate CR to create at least one automated test. It > seems that all of the new tests for this bug are manual. > Can you also please investigate how will we work if instead of "move" the > user will "resize" the window to another screen.
Also please check that undecorated and/or non-resizable windows works as well. > >> >> Hello, >> >> Could you review the fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8175293 >> webrev: http://cr.openjdk.java.net/~alexsch/8175293/webrev.00 >> >> The fix for the JDK-8147440 shifts a window position while it is dragging >> from one display to another. >> This causes that sometimes there is a native event which sets the window >> position back before the window was shifting when the mouse button is up. >> The current fix postpones the window shifting after the WM_EXITSIZEMOVE >> event. >> >> Now all windows moving from one display to another and display DPI changing >> are handled in WWindowPeer.checkDPIChange(...) method. >> This includes the following use cases: >> - changing the DPI of the current display >> - moving a window from one display to another >> - set the window location to position on another display >> >> Thanks, >> Alexandr. >> >> >
