On Thu, 3 Nov 2022 21:21:42 GMT, Marius Hanl <mh...@openjdk.org> wrote:
>> The problem here is, that the `AnchorPane` does not use its snapped insets.
>> Therefore, the fix is to replace all `getInsets().getXXX` calls with their
>> corresponding `snappedXXXInset()` methods.
>>
>> Note: The reason the `AnchorPane` inside a `TitledPane` is blurry in the
>> first place is because a `TitledPane` applies padding to its content.
>> Line 2995 in `modena.css`:
>>
>> .titled-pane > .content > AnchorPane {
>> -fx-padding: 0.8em;
>> }
>>
>> which translates to 9.6px.
>>
>> EDIT: This is btw a good example of the JUnit 5 feature `@ParameterizedTest`
>> with `@ValueSource`
>
> Marius Hanl has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 8295078: Replace JUnit4 with Junit5 imports
modules/javafx.graphics/src/main/java/javafx/scene/layout/AnchorPane.java line
353:
> 351:
> 352: if (leftAnchor != null) {
> 353: x = snappedLeftInset() + leftAnchor;
Question: should we use unsnapped coordinates in the computations, and only
snap at the final stage?
For example, if leftAnchor is 0.5 the child will be positioned between the
pixels, so to speak.
Or is this indeed an intended functionality?
modules/javafx.graphics/src/test/java/test/javafx/scene/layout/AnchorPaneTest.java
line 765:
> 763: double snappedPaddingY = child.snapPositionY(padding);
> 764:
> 765: assertEquals(snappedPaddingX, boundsInParent.getMinX(), 0.0001);
EPSILON constant perhaps?
-------------
PR: https://git.openjdk.org/jfx/pull/910
