Label height is ignored if the font size is larger

[rjwills28]

This is a repeat of issue #3344, which was initially fixed in #3354, however this fix has knock on consequences for labels in the Byte Monitor widget reported in #3518.

The fix for the label height was to set:

jfx_node.setMinSize(Control.USE_PREF_SIZE, Control.USE_PREF_SIZE);
jfx_node.setMaxSize(Control.USE_PREF_SIZE, Control.USE_PREF_SIZE);

But setting the min size like this caused the labels in the Byte Monitor widget to not show. Removing the setMinSize() fixed the Byte Monitor issue but undid the fix for the label height.

I believe setting both min and max to the same thing tells JavaFX to 'really' set this size. My guess is that removing the one let it treat the preferred size as optional again.

[abrahamwolk]

I have created a work-in-progress pull request attempting to fix this issue: #3537

I will continue to test and perhaps improve the pull request next week.

[rjwills28]

Great - thanks for looking at this! I'll have a test too.

[rjwills28]

I've done a bit of testing and a bit of digging. While the changes in this branch initially appear to work I have found that it still does not work consistently, that is 1 out of 10 times the labels will not render.

There is a bug in the Byte Monitor updateChanges() code. The pane node in this widget has been set to not be managed by the parent. For all other widgets that do this (e.g. Combo Box, LED, Meter, ScaledSlider etc) the line jfx_node.layout() is always called at the end of updateChanges() independent of whether it is 'dirty' or not. E.g. ComboBox.updateChanges() . This is because it is up to the user to call layout if it is not managed by the parent.

Therefore I think the first order fix is just to add jfx_node.layout() after line 449:

phoebus/app/display/representation-javafx/src/main/java/org/csstudio/display/builder/representation/javafx/widgets/ByteMonitorRepresentation.java

Line 449 in d6d8ea4

}

On testing this, again, seems to fix the issue. However once again, testing multiple times I find that occasionally the labels to do render. What's more interesting is that I can reproduce this issue with other 'not managed' widgets, for example try a ComboBox. When it fails, both the Byte Monitor and Combo Box are missing text labels...

A little more debugging and I've found that it always fails when jfx_node.getParent().isNeedsLayout() returns false in the Byte Monitor/ Combo Box updateChanges().

Not 100% sure what this really means yet or how to fix it. The documentation for the .layout() method suggests that calling this method will the parent is doing a layout results in a no-op so is it possible that the the Byte Monitor is trying to update its layout while the parent is performing a layout and hence the jfx_node.layout() in the Byte Monitor gets ignored?

[abrahamwolk]

@rjwills28 Interesting! I am also able to solve the issue by removing the calls to setManaged(false). @kasemir, you mentioned in #3518 (comment) that setManaged(false) was added to widgets in order to reduce the amount of processing; do you know what the approximate overhead would be if the widgets were to be set to being managed again?

[abrahamwolk]

@rjwills28: I have updated the pull request #3537 with an alternative fix based on your observation that layout() always should be called in updateChanges(). With this version of the fix, I no longer get the ~10% probability that the labels don't appear.

[kasemir]

setManaged(false) was added many years ago, like this commit from 2019 kasemir/org.csstudio.display.builder@c31d701, before phoebus, when the code was still running under Eclipse.
Back then, running an example like "many_texts.bob" that creates 2000 text updates in jProfiler would show the majority of time spent in JFX layout code unless we disable the "managed" behavior.

That's probably still a good idea for simple widgets like text updates, but we did later revert widgets back to "managed" mode, like #1274

Might be a good idea to run displays with many byte monitors under a profiler, ideally on Linux because that's what matters most in the control room, and see if managed or not makes a difference.

[rjwills28]

@abrahamwolk - In reply to question from PR: #3537

@rjwills28: You mention in #3533 that you can reproduce the issue with other widgets. Perhaps other widgets need should be fixed as well. I have, however, not been able to reproduce it with the Combo Box widget. Do you have a way of reproducing the issue with other widgets?

I was able to reproduce the issue with another widget in the exact same way as the Byte Monitor widget. That is to say, one BOB screen with a label widget followed by a Combo Box widget. Then another BOB screen with a Navigation tab widget with one of the tabs pointing to this first BOB file.

But I should stress that it only happens a fraction of the time. I'm attaching a video where I am just switching between the 2 tabs. Most of the time everything is fine but skip forward to ~49 seconds and you will see that the Combo Box text does not appear.

Screencast.from.2025-09-22.20-30-46.webm

This is after having pulled in the latest changes. Note the Combo Box widget does already have the layout() call in its updateChanges() method so the fix we have implemented for the Byte Monitor widget is already there. I think there is still some sort of race condition happening here.