Thank you John, I think it's the right approach. We probably should also look at the other containers to make sure all of them snap properly. This is a problem especially visible on Windows at fractional scales.
Cheers, -andy From: openjfx-dev <openjfx-dev-r...@openjdk.org> on behalf of John Hendrikx <john.hendr...@gmail.com> Date: Wednesday, February 5, 2025 at 10:20 To: openjfx-dev@openjdk.org <openjfx-dev@openjdk.org> Subject: Duplication in HBox/VBox Hi list, I wish to address the huge amount of duplication in HBox/VBox as it is error prone when doing modifications there. I'm in the process of fixing these classes so that they no longer layout their children off-by-one-pixel on render scales other than 1 (they will often not fully fill the box, missing 1 pixel, due to rounding errors or incorrect snapping of values). There's two thing I want to do: - Make it clear which values are snapped, raw or near-snapped by using prefixes "raw", "snapped" and "near" in variables and method names. Much of the code incorrectly assumes that adding, subtracting or multiplying two snapped values results in a snapped value. This is not true, it is only a nearly snapped value; it must be resnapped if returned. By meticulously tracking what is snapped, almost snapped and raw it is easier to call snap functions only when needed. This is mostly renaming of variables. There are numerous small problems in these classes (and probably other classes) where values are not resnapped after floating point calculations. - Deduplicate much of the code (I suspect 80-90%) by introducing a package private class AbstractBox, which holds the duplicated code. Since I dislike doing the same work twice, I did some research, and introducing a package private superclass is a binary compatible change, even if duplicated public methods are moved to AbstractBox. Javadoc will also handle this correctly and will completely hide AbstractBox; public methods in AbstractBox will show up in HBox/VBox documentation, and HBox/VBox will be said to extend Pane still. An example of this pattern is AbstractStringBuilder, a package private class from which StringBuilder and StringBuffer inherit. At the time this was a binary compatible change when StringBuilder was introduced. By looking at the Javadoc, you can't see it is there (https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/StringBuilder.html) and even its public methods are show as being part of StringBuilder or StringBuffer directly. Let me know what you think. --John
