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

[Kevin Rushforth]

On Wed, 16 Dec 2020 19:25:56 GMT, Frederic Thevenet <fthevenet at openjdk.org> wrote:

>> Looking the git blame, it appears the orignal and copy diverged on commit 55cf799de20b6fbf9ee31850b75c34389c8a28f2 "Baseline offset depends on layout bounds which are calculated during layout".
>> I really can't say if TextFlow needs that as well, so I left it out and just adapted the methods as discussed above.
>> 
>> Maybe someone more knowledgeable about font rendering and the TextFlow implementation can comment on whether or not it should be added to TextFlow (presumably in a follow up?)
>
> There is still a remain 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.

-------------

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