On Thu, 27 Aug 2026 22:03:53 GMT, Michael Strauß <[email protected]> wrote:
> For the longest time, I've had the impression that scrolling in JavaFX is not > quite right. Looking at it, that suspicion is quickly confirmed: the scroll > distance is incorrectly divided by the render scale. > > To reproduce, open MonkeyTester and scroll a ListView. On Windows 11 with a > system setting of 3 lines per detent, the ListView scrolls exactly 3 lines at > 100% render scale, 2 lines at 150% render scale, and 1.5 lines at 200% render > scale. > > The render scale conversion was introduced in 2015 when High-DPI support was > added. However, mouse wheel rotation is a dimensionless number, it shouldn't > be scaled at all. A line is a line, no matter the render scale. > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). Here's how scrolling works: * On Windows, `WM_MOUSEWHEEL` is normalized to a dimensionless wheel rotation using `GET_WHEEL_DELTA_WPARAM(wParam) / WHEEL_DELTA`. * GTK behaves similarly: `process_mouse_scroll` maps the discrete `GDK_SCROLL_UP/DOWN/LEFT/RIGHT` directions to +1 or -1. Both Windows and GTK then call `View.notifyScroll`, which ends up in `GlassViewEventHandler.handleScrollEvent`. * macOS uses a different path. All `NSScrollWheel` events, including conventional mouse wheels, trackpad gestures, and inertia, are routed through: `MacGestureSupport.scrollGesturePerformed` -> `View.notifyScrollGestureEvent` -> `GlassViewEventHandler.handleScrollGestureEvent`. They do not use `handleScrollEvent`, which explains why this PR produces no observable difference on macOS. Additionally, Glass uses a platform scale of 1.0 on macOS because Cocoa reports event coordinates in the same coordinate system JavaFX uses for layout. Removing the platform scale division from `handleScrollEvent` is therefore correct for Windows and Linux, as both platforms report a dimensionless scroll number. However, `handleScrollGestureEvent` is different: on Windows, touch-manipulation events also end up here. Windows touch coordinates and translations are reported in hundredths of physical pixels. `ViewContainer::NotifyGesturePerformed` divides them by 100, producing physical-pixel distances; `handleScrollGestureEvent` must then divide those distances by the platform scale to convert them to JavaFX layout coordinates. We can't just remove the division here. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2282#issuecomment-5514791068
