On Fri, 5 Aug 2022 18:38:28 GMT, Kevin Rushforth <k...@openjdk.org> wrote:
>> When using the Windows Narrator screen reader on a Hi-DPI screen, the >> visible focus is drawn in the wrong location and with the wrong size. This >> happens because the the JavaFX Windows accessibility code that returns the >> screen bounds of the requested UI element does not take the screen scale >> into account. >> >> The fix is to adjust the bounds by the screen scale before returning it. >> >> You can test it on a Windows machine with scaling set to >= 125% as follows: >> 1. Turn on Windows Narrator >> 2. Run any JavaFX program with at least UI controls, for example, >> `hello.HelloTextField` in `apps/toys/Hello` >> 3. TAB between the controls >> >> Without the fix, Narrator shows the focus indicator in the wrong position >> and is too small. With the fix, it is correct. While testing this, I >> discovered an unrelated (and preexisting) bug where the focus indicator for >> a TextField or TextArea whose content is larger that the control (and is >> displayed with scroll bars) is not clipped to the visible area. This happens >> regardless of screen scale. I will file a follow-up bug for this. >> >> Note that this bug is specific to Windows. It does not occur on macOS, which >> works correctly on a retina or non-retina display. > > Getting back to this, I discovered what the problem was with some > multi-screens layouts when two screens have a different scale. Computing the > platform x and y by simply multiplying by the scale is not right, and only > work for a screen that touches the origin of the virtual screen space (in > both X and Y). When the secondary screen is to the left or above the primary > screen, the simple (but incorrect) calculation gives the same result as the > correct calculation. For a secondary screen below or to the right of the > primary screen, it doesn't. Simply scaling the coordinate about the origin > produces a value that is either too small or too large when the two screens > have a different scale. > > The right fix is to use the `Screen.toPlatformX` and `Screen.toPlatformY` > methods, which take this into account, and translates the coordinate to the > right origin, scales it, and then translates it back. In order to do that, I > needed to get the `Window` from which I could get the `Screen`, which > required making the quantum `WindowStage` class public along with its > `getWindow` method. This is an internal implementation class, so is not a > concern. > > I've tested this updated version in various combinations of layout and screen > scales, and everything now works as expected. @kevinrushforth : on windows, a window can be positioned to span two monitors. you can't do this on Mac - once dropped, only a part of the window remains (on the monitor which contains the title bar, it seems). but on windows, the app continues to work on both monitors. what happens then? ------------- PR: https://git.openjdk.org/jfx/pull/853
