On Wed, 16 Dec 2020 19:25:56 GMT, Frederic Thevenet <ftheve...@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
