Duplication in HBox/VBox

[Andy Goryachev]

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-retn at openjdk.org> on behalf of John Hendrikx <john.hendrikx at gmail.com>
Date: Wednesday, February 5, 2025 at 10:20
To: openjfx-dev at openjdk.org <openjfx-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250205/307da749/attachment.htm>