JavaFX Content Rendering & Resizing and Font Bugs In Linux

[Ty Young]

On 1/17/19 12:55 PM, Siddhesh Rane wrote:
> January 16, 2019 11:31 PM, "Ty Young" <youngty1997 at gmail.com> wrote:
>
>> How else is percentage based UI sizing besides DoubleBinding(s)? Isn't column restraints just the
>> same thing but aligns everything to a column?
>>
>> I have to ask(again) as to why minWidth/maxWidth, minHeight/maxHeight, prefWidth/prefHeight aren't
>> read only if this is going to be an *always* realistically going to be an issue.
> Column constraints don't use any bindings, neither do any other layout panes.
> {min,pref,max} width/height are merely hints for a parent to layout the child. They are not the final authority on child size. The actual final size of a child is set by calling Node#resize on it, which is what the parent does during the Parent#layoutChildren call. During this call the parent knows about its own size and can split that space among the children.
> A rogue parent could completely ignore these hints and resize the child to whatever it wants.


The documentation on the sizing says that they override the computed size.


>
> On your second point, it is only an issue if you use it in the wrong way, without understanding.


Excuse me? There is no documentation AFAIK stating that this would ever 
be an issue nor would anyone look at the UI and think that a GridPane is 
necessary to achieve such a basic layout. The use of GridPane seems more 
like a hacky workaround for something JavaFX seemingly has no other way 
to achieve with more appropriate layout management nodes(VBox, HBox, 
etc) without side affects.


I wanted to place the buttons and Scrollpane in a horizontal fashion, so 
I used an HBox. I wanted to dynamically size the nodes based on a 
percentage of the window's total width/height, so I used property 
bindings to force content to the desired correct. If that causes issues 
then maybe all controls should get a supported percentage based way to 
set the width/height like GridPane's columns with appropriate layout 
nodes so people don't try doing this sort of thing.


> You bound the minWidth of a scrollpane's content to 85% of the scrollpane's widthProperty (which is actual width).
> When you resize the scrollpane to <85% of its original size, its content still has the old minWidth property which is greater than the current width of the scroll pane. So the scrollpane shows horizontal bar. This is not a bug. widthProperty is supposed to be valid after layout.


This explains the ScrollPane horizontal scrollbar glitching out but 
doesn't explain TableView's horizontal scrollbar.


>
> Use bindings for size if you want to do some advanced sizing. Like size matching unrelated nodes with different parents to get some visual effect. You could create a custom textarea that binds minWidth to the number of characters in the first line.
> I have never had a use case but someone else might.
> Use it for cases where there is no mutual dependency or "race condition".
>
>>> I saw your code and I can confirm this is the main cause.
>>> If you want a 15-85 % split, you should have used a GridPane with two columns with the given
>>> percentage constraints.
>> This works for the buttons/scrollpane but what about the subcontent? TableView's scrollbars also
>> glitch out in the exact same way.
> Set scrollpane to fit to width. Add a gridpane with a single column whose column width is set to 85%. Set gridpane alignment to center. Drop the bindings and your problems will be solved.


It isn't completely solved but it is better I guess. ScrollPane's 
horizontal bar no longer glitches out and resizing performance has 
increased majorly. TableView still glitches out from time to time and 
app content is still jumping all over the place. Bindings are still 
needed for the size of the main GridPane and other misc nodes. It seems 
to be a bug caused by indirect resizing of the table itself...


And the vertical scrollpane bar is missing from the Overview content. 
Setting the show policy to Always shows it being there where it should 
be and is usable(regardless of policy) via scroll wheel. No other 
section has this issue.


Font rendering is also still an issue...


>
>> SceneBuilder's lack of UI snapping compared to Netbean's Swing builder makes it incredibly
>> difficult to get anything remotely pixel perfect without banging your head against a wall. Separate
>> controller classes and FXML annotations everywhere isn't really desirable either. I originally
>> entertained the idea of doing it all in FXML only to quickly discard the idea.
> If you are talking about snapping like in aligning to other UI elements, then its there and you dont need it with the rought layout. If you mean snapping to pixels, JavaFX has it inbuilt and on by default.


It is but it is incomplete. Try resizing a Button in both SceneBuilder 
and Netbean's Swing builder to the bottom right after first snapping to 
the top left. The button will snap perfectly to both in the Swing 
builder but not SceneBuilder.


>
> Regards
> Siddhesh