-
Notifications
You must be signed in to change notification settings - Fork 492
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8204568: Relative CSS-Attributes don't work all time #397
Conversation
👋 Welcome back arapte! A progress list of the required criteria for merging this PR into |
Webrevs
|
/reviewers 2 |
@kevinrushforth |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is taking me longer to review than I expected, because I ran into some anomalies while doing some additional testing. There is an unexpected change in behavior for nested panes with relative sizes. We need to understand this change before this is integrated.
I added a modified version of the original test program to the JBS bug report that creates a scene graph like this, where the root and both parent nodes specify the font size in absolute pixels:
Root // -fx-font-size: 96px
P1 // -fx-font-size: 48px
P2 // -fx-font-size: 36px
L1 (unset), L2 (18px), L3 (0.5em) // All three had padding and bg radius at 0.5em
The above scene graph works as expected with the fix, whereas before the fix label L3 had incorrect padding.
I then added a button to cycle through 4 modes replacing first P2, then P1, then the Root with what would be "equivalent" relative font sizes if the definition of an "em" is its parent's font size.
Root // -fx-font-size: 96px
P1 // -fx-font-size: 48px
P2 // -fx-font-size: 0.75em
L1 (unset), L2 (18px), L3 (0.5em) // All three had padding and bg radius at 0.5em
Root // -fx-font-size: 96px
P1 // -fx-font-size: 0.5em
P2 // -fx-font-size: 0.75em
L1 (unset), L2 (18px), L3 (0.5em) // All three had padding and bg radius at 0.5em
Root // -fx-font-size: 8.0em
P1 // -fx-font-size: 0.5em
P2 // -fx-font-size: 0.75em
L1 (unset), L2 (18px), L3 (0.5em) // All three had padding and bg radius at 0.5em
Things start getting unexpected when there is a parent with a relative font size, and the label had a relative font size (e.g., L3 when P2 is relative). When all nodes are relative (the last case), the padding size is completely wrong.
Btw, I'm not currently worried about the calculation of the font size itself; this fix is intended to be a targeted fix that doesn't change the calculated font size (separately, we could look at that, but it would be much riskier and is out of scope for this bug fix). What I want to make sure is that in all cases, specifying the padding or other sizes in a node in ems will be relative to whatever the calculated font size is.
The cause of wrong behaviour in the scenario that Kevin has mentioned in previous comment :
Changes in commit:
Tests are written only using Label control. The issue and its fix can also be observed using other controls inherited from Labeled class.(RadioButton, CheckBox, Button,..) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The fix looks good to me, as do the new unit tests. I tested it with the test program I wrote as well as by running your new unit test with / without the fix. As with any CSS fix, the two things we need to ensure are that there are no functional regressions and that there is no significant performance hit.
I have a a couple questions:
-
The new method is only needed for Labeled because of the way it constructs the child graph, right? Is there anything that would preclude some other control from using this in the future, if a similar situation would arise?
-
Have you done any performance testing to ensure that there are no regressions? I wouldn't think there would be, given that this only applies the fix when the size of a Labeled control changes.
I also left some inline suggestions and questions.
modules/javafx.controls/src/test/java/test/javafx/css/PropertySizeTest.java
Show resolved
Hide resolved
modules/javafx.controls/src/test/java/test/javafx/css/PropertySizeTest.java
Outdated
Show resolved
Hide resolved
modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java
Outdated
Show resolved
Hide resolved
Yes, new method is needed only because the font size property is shared between parent(Labeled) and child(LabeledText) control. Given that method only recalculates relatively sized properties, I can't think of anything that would preclude it from reuse.
I did a performance test today using 10,000 Label controls. The program is attached to JBS. Time in ms: Without change: Also a point to note is that, this scenario occurs only when the sizes are provided such that Label's and LabeledText's font size does not match. otherwise the recalculation of properties does not happen and performance remains same. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the response to the performance question. For the stress test you added, the performance hit seems reasonable to achieve correct rendering behavior. Especially since it is only applied for those cases where needed and only the first time, or when the font size changes.
I left a few wording suggestions inline.
modules/javafx.controls/src/test/java/test/javafx/css/PropertySizeTest.java
Outdated
Show resolved
Hide resolved
modules/javafx.controls/src/test/java/test/javafx/css/PropertySizeTest.java
Outdated
Show resolved
Hide resolved
modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java
Outdated
Show resolved
Hide resolved
modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java
Outdated
Show resolved
Hide resolved
modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java
Outdated
Show resolved
Hide resolved
Thanks for the review comments. Please take a look at new commit. I have rephrased comment statements and made corrections as per review comments. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two additional comments, and otherwise looks good to me.
modules/javafx.controls/src/test/java/test/javafx/css/PropertySizeTest.java
Outdated
Show resolved
Hide resolved
modules/javafx.controls/src/test/java/test/javafx/css/PropertySizeTest.java
Outdated
Show resolved
Hide resolved
Thanks for the review, both the comments are addressed in next commit. Please take a look. |
@arapte This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 1 new commit pushed to the
Please see this link for an up-to-date comparison between the source branch of this pull request and the ➡️ To integrate this PR with the above commit message to the |
/integrate |
@arapte Since your change was applied there have been 2 commits pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit 9c7cf17. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Issue is that the size of properties that are relatively(
em
) sized is not computed correctly when the reference-fx-font-size
is also specified relatively and is nested.Fix is a slight variation of an earlier suggestion in the PR.
Fix is very specific to this scenario and did not show any side effect nor any test failure.
There are 12 new unit tests added along with fix:
Progress
Issue
Reviewers
Download
$ git fetch https://git.openjdk.java.net/jfx pull/397/head:pull/397
$ git checkout pull/397