RFR: 8211294: ScrollPane content is blurry with 125% scaling

Frederic Thevenet fthevenet at openjdk.java.net
Thu Dec 17 17:48:58 UTC 2020

On Thu, 17 Dec 2020 00:24:49 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> There is still a remaining scaling issue, I'm afraid: snapped insets coordinates are cached after they've been computed and only updated  when the inset  (or a related property, such as shape or border) changes or if the snapToPixel property changes.
>> This means that on a setup with more than one screen with different scales, when moving the application's window from one screen to the other, controls that were snapped on the first screen nor longer are once moved on the second one, and therefore appear blurry.
>> We could possibly listen to `Window::renderScaleXProperty` and  `Window::renderScaleYProperty` and call ` updateSnappedInsets`& `requestLayout` when one changes?
> Good point. We would need some way to invalidate the cached values if the screen scale changes.
>> We could possibly listen to `Window::renderScaleXProperty` and `Window::renderScaleYProperty` and call `updateSnappedInsets` & `requestLayout` when one changes?
> A layout will happen anyway as the result of a Window moving to another screen, so really it's only the cached snapped insets that need to be recalculated. I don't know whether a listener is the best approach, since it would need to handle the case where the Window changes (either because the scene changed or the scene was added to a new window), which would present similar challenges to what we face with treeVisible.
> Another possibility is for `updateSnappedInsets` to also cache the scaleX/Y at which the snapped insets were computed. The `snappedXXXXX` methods could check the current scale against the cached scale (a simple == test) and call `updateSnappedInsets` if the scale changes.

I've opted for the cache and check for screen scale solution, as I agree it presents less risks of leaked or missing listeners down the road.
There's a slight unexpected drawback I've noticed, though, which is that the repaint for the affected Region does not seem to occur right away on moving the window to another screen, but only once the Region is interacted with (e.g. hovering the mouse over it).


PR: https://git.openjdk.java.net/jfx/pull/308

More information about the openjfx-dev mailing list