On Wed, 16 Dec 2020 18:14:42 GMT, Frederic Thevenet <ftheve...@openjdk.org> wrote:
>> Region is part of the public API, so any change to increase the visibility >> of fields or methods would require a new enhancement with a CSR and >> justification as to why it is needed as public API. We wouldn't do that just >> to fix this bug. >> >> Does TextFlow really need the package-scope snap methods from Region? I was >> thinking you would modify the copied `computeChildXXXAreaWidth/Height` >> methods to call the public `snapSpaceX/Y` methods (the ones that don't take >> `snap` as a parameter). > > 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? ------------- PR: https://git.openjdk.java.net/jfx/pull/308
