On Tue, 19 Mar 2024 13:16:48 GMT, Lukasz Kostyra <lkost...@openjdk.org> wrote:
>> There were two different problems with this test's stability and HiDPI and >> both were fixed with this change. >> >> The whole reason for this tests lack of stability comes with how Windows >> calculates window position when using HiDPI. When window's X/Y coordinates >> are not provided by the application, they are (generally speaking) randomly >> selected by Windows. X/Y are picked as two integers, and afterwards the >> HiDPI scaling is applied. With fractional scaling like 125% this can cause >> X/Y coordinates to have fractional values. >> >> When performing a screen capture, Robot takes a generous estimate of >> window's position and dimensions. This is done by taking provided X/Y >> coordinates (in case of this test, stage's X/Y coords), multiplying them by >> scaling (ex. 1.25) and then flooring the result. Similar estimation is done >> to opposite coordinates - we take X/Y coords, add width/height to them >> respectively, multiply them by scaling and ceiling them. As a result, we >> have minX/Y and maxX/Y coords of capture region, which is used to calculate >> capture region's width and height. The first problem with test's stability >> is right here - the test did not take this calculation and floor/ceil >> operations into account, which with appropriately randomized window >> coordinates could cause discrepancy between expected width/height and >> actual. This logic that is used by `getScreenCapture()` seems to be >> necessary and good, so to remedy the problem I replicated those calculations >> on test side. >> >> Another problem came after that - fractional X/Y values caused capture to >> not always line up with pixel layout, which made the 1-pixel border of >> capture sometimes incorrect (an average of stage's MAGENTA color and >> whatever background happened to be under the displayed stage). This means we >> cannot exactly expect those pixels to have exactly MAGENTA color when the >> system has fractional HiDPI enabled. To help that, the test now doesn't >> check for correctness of the 1-pixel border of captured image. I feel this >> still gives us enough confidence that the Robot screen capture works >> properly, while stabilizing the test on all systems. >> >> I briefly considered an alternative approach to hard-set X/Y values but >> doing it this way gives us a bit more robustness, makes the test independent >> of Stage's X/Y coordinates which matter quite a lot. >> >> Verified this change on macOS and especially on Windows - ran the test on >> Windows 50 times each on 125% and 100% scaling and noticed no intermittent >> failures. > > Lukasz Kostyra has updated the pull request incrementally with one additional > commit since the last revision: > > Fix cast formatting Fix looks good to me. I confirm that the test no longer fails on my Windows system (running at 1.25x scale). ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1403#pullrequestreview-1947446088
