Re: Understanding Layout
Hi Scott,
On 18.12.2014 22:49, Scott Palmer wrote:
Short Version:
Is there good documentation on how JavaFX performs layout? (Not specific
layouts, but layout in general.)
Not an official documentation I'm afraid (at least I don't know of any),
just the javadoc and a few blog posts:
Amy Fowler made some short introduction about layouts here:
https://amyfowlersblog.wordpress.com/2011/06/02/javafx2-0-layout-a-class-tour/
I tried to explain some parts of the layout process that were confusing
people from time to time (based on the JIRA issues that were reported to
me):
https://blogs.oracle.com/jfxprg/entry/the_peculiarities_of_javafx_layout
(I'm sorry I never got to make part 2 :-( ).
Long Version:
I was looking into a layout issue in ControlsFX (BreadCrumbBar width is
reported incorrectly and it doesn't behave when right-aligned).
What I found is that Parent and SkinBase assume that layout has already
occurred on child nodes when computing the preferred width/height. The
JavaDocs indicate this is a known assumption:
* Calculates the preferred width of this {@code SkinBase}. The default
* implementation calculates this width as the width of the area
occupied
* by its managed children when they are positioned at their
* current positions at their preferred widths.
Parent.computePrefWidth(double height) javadocs contain the exact same
comment.
Note however that the Region class documents Region.computePrefWidth(double
height) differently. It simply states:
* Computes the preferred width of this region for the given height.
* Region subclasses should override this method to return an
appropriate
* value based on their content and layout strategy. If the subclass
* doesn't have a VERTICAL content bias, then the height parameter can
be
* ignored.
Node.prefWidth(double height), which is what
Control.computePrefWidth(double height) delegates to if there is no
SkinBase, clearly states:
Returns the node's preferred width for use in layout calculations.
It's the for use in layout calculations part, combined with the fact that
prefWidth relies on the layout having already happened, that confuses me.
Clearly layout is working in most cases, so this must all work out in the
general case. But as I understand it layout happens top-down, so
constraints imposed by the parent container must be accounted for when
positioning and sizing the children. That implies that the child nodes are
not yet laid out when their preferred size is queried.
I fixed the issues I was having with BreadCrumbBar by overriding the
implementation of computePrefWidth(double height) with one that does not
care about the current X position of the child Nodes. It still relies on
the layout bounds via Node.prefWidth(double height), and duplicates some of
the calculations that an actual layout will do, but it worked to solve the
problems of right-aligned layout and a widthProperty that was clearly lying.
I feel like I am missing something fundamental about how Layout works
though.
Is there documentation that explains the general layout algorithm and how
to make sense of the apparent circular dependency?
The way it should work is that pref* min* max* methods
should be able to compute the layout without the layout actually
happening. This is basically a kind-of 2-pass top-down layout:
take a root (or any other parent in a tree) you want to layout. First,
the computation of size hints happens (and might be traversing down the
tree).
After this stage, you know the size hints of the root's children, but no
layout happened yet.
Now the layout happens and the children are given their sizes (which
might not be equal to pref size), the layout is done recursively on the
children (now they know their final size they have all the information).
Theoretically, you could even cache the size hints in your skins (until
some of their prerequisites change) and use them at any stage of the
layout pass, even as the parent's sizes change during the layout.
This approach also means that size hints cannot depend on their
ancestor's size (which is something many people tried to do).
But it seems you already understand all this well.
Now the confusing parts:
* Some default implementation look like they rely on the layout, but
this is actually because they have no layout by default. Or more
commonly, the layout does just the resize, not movement. This means we
can use layout bound's x, y already at compute* methods as this is
something not managed by Parent and may be set through relocate()
explicitly by the developer. I see SkinBase does actually moves the
children by default (to contentX, contentY) and yet still uses layout
bounds in compute* methods. This might lead to a bug in certain cases
IMO, but usually would work as the position does not change. Maybe some
child's margin change could break this, I would have to play with it to
find out.
Probably one JIRA task here
Review: null pointer in pulse logger
Kevin, a small fix in pulse logger, fixing a non-toxic null pointer in pulse logger. https://javafx-jira.kenai.com/browse/RT-39703 the one line diff is in the Jira. -- David Hilldavid.h...@oracle.com Java Embedded Development A man's feet should be planted in his country, but his eyes should survey the world. -- George Santayana (1863 - 1952)
In(Sanity) Testing Mondays
Reminder, Monday is our weekly sanity testing. You can find your testing assignment at: https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing Also please remember that the repo will be locked from 1am PST until 1pm PST. Happy testing! Thanks, Vadim
Re: Is this the end of support raspberrry pi?
On 12/19/14, 1:23 AM, Ladislav Török wrote: In JavaFX Jira is enough bugs marked as Won't Fix lately. For example: RT-33958, RT-33959, RT-33960, RT-34735 Is it only valid for Ensemble8 running on Raspberry Pi or support javaFX on Raspberry Pi? It's amazing that JavaFX running on Raspberry Pi: I am very grateful for it. Thanks. Keep it up... It is less to do with the support of the PI, but rather a realization that we don't have the internal resources to concentrate on the samples on an embedded platforms. Ensemble8 in particular is a bit of a monster - it is very large (both for memory used and classes consumed, and then of course the index parsing it does on startup) and does a lot of things that are hard to speed up on the Pi. Ensemble8 runs reasonably well on the i.MX6, which is closer to the platforms that that we might support commercial use on. Even there it does not make a great example of a application. Rather than re-re-triage these sets of tasks, I reluctantly closed them, knowing that I can reopen them if and when we have the resources to do the rework needed. Dave -- David Hilldavid.h...@oracle.com Java Embedded Development A man's feet should be planted in his country, but his eyes should survey the world. -- George Santayana (1863 - 1952)
Re: Is this the end of support raspberrry pi?
So, the community challenge is to rewrite this beast to make it run smoothly on a pi? -Sven Am 19.12.2014 17:47 schrieb David Hill david.h...@oracle.com: On 12/19/14, 1:23 AM, Ladislav Török wrote: In JavaFX Jira is enough bugs marked as Won't Fix lately. For example: RT-33958, RT-33959, RT-33960, RT-34735 Is it only valid for Ensemble8 running on Raspberry Pi or support javaFX on Raspberry Pi? It's amazing that JavaFX running on Raspberry Pi: I am very grateful for it. Thanks. Keep it up... It is less to do with the support of the PI, but rather a realization that we don't have the internal resources to concentrate on the samples on an embedded platforms. Ensemble8 in particular is a bit of a monster - it is very large (both for memory used and classes consumed, and then of course the index parsing it does on startup) and does a lot of things that are hard to speed up on the Pi. Ensemble8 runs reasonably well on the i.MX6, which is closer to the platforms that that we might support commercial use on. Even there it does not make a great example of a application. Rather than re-re-triage these sets of tasks, I reluctantly closed them, knowing that I can reopen them if and when we have the resources to do the rework needed. Dave -- David Hilldavid.h...@oracle.com Java Embedded Development A man's feet should be planted in his country, but his eyes should survey the world. -- George Santayana (1863 - 1952)
Re: Is this the end of support raspberrry pi?
On 12/19/14, 12:02 PM, Sven Reimers wrote: So, the community challenge is to rewrite this beast to make it run smoothly on a pi? If someone wants to look for hot spots (profiling and such), then that certainly would help. And after that, perhaps some donated code would be nice :-) The app is nicely designed in some ways - easily extensible and such, but for a smaller device, those design features don't fit as well. In the modern world of app design, it really makes sense to create a clean app, and then speed it up. I know that I have found that early optimization is problematic as I was often wrong at where the choke points were. Ensemble was made on and for the desktop CPU, and it shows in startups time. Dave -Sven Am 19.12.2014 17:47 schrieb David Hill david.h...@oracle.com mailto:david.h...@oracle.com: On 12/19/14, 1:23 AM, Ladislav Török wrote: In JavaFX Jira is enough bugs marked as Won't Fix lately. For example: RT-33958, RT-33959, RT-33960, RT-34735 Is it only valid for Ensemble8 running on Raspberry Pi or support javaFX on Raspberry Pi? It's amazing that JavaFX running on Raspberry Pi: I am very grateful for it. Thanks. Keep it up... It is less to do with the support of the PI, but rather a realization that we don't have the internal resources to concentrate on the samples on an embedded platforms. Ensemble8 in particular is a bit of a monster - it is very large (both for memory used and classes consumed, and then of course the index parsing it does on startup) and does a lot of things that are hard to speed up on the Pi. Ensemble8 runs reasonably well on the i.MX6, which is closer to the platforms that that we might support commercial use on. Even there it does not make a great example of a application. Rather than re-re-triage these sets of tasks, I reluctantly closed them, knowing that I can reopen them if and when we have the resources to do the rework needed. Dave -- David Hilldavid.h...@oracle.com Java Embedded Development A man's feet should be planted in his country, but his eyes should survey the world. -- George Santayana (1863 - 1952) -- David Hilldavid.h...@oracle.com Java Embedded Development A man's feet should be planted in his country, but his eyes should survey the world. -- George Santayana (1863 - 1952)
Re: Understanding Layout
Thanks Martin that helps a bit.
Here's a test case that reproduces the layout issue I was seeing. The
layout code is very basic and computation of the size is left to the base
class. The computed width is wrong.
The error seems to be that the compute* methods in SkinBase simply don't
apply. I believe this is the issue I had with BreadCrumbBar in ControlsFX.
Would that be your evaluation as well?
It seems odd, since the compute* methods in Parent and SkinBase only look
at *managed* nodes in the calculation. Doesn't that partially
contradict, ...we
can use layout bound's x, y already at compute* methods as this is
something not managed by Parent and may be set through relocate()
explicitly by the developer., because managed nodes would be positioned by
the layout code.
Cheers,
Scott
On Fri, Dec 19, 2014 at 4:12 AM, Martin Sladecek martin.slade...@oracle.com
wrote:
Hi Scott,
On 18.12.2014 22:49, Scott Palmer wrote:
Short Version:
Is there good documentation on how JavaFX performs layout? (Not specific
layouts, but layout in general.)
Not an official documentation I'm afraid (at least I don't know of any),
just the javadoc and a few blog posts:
Amy Fowler made some short introduction about layouts here:
https://amyfowlersblog.wordpress.com/2011/06/02/
javafx2-0-layout-a-class-tour/
I tried to explain some parts of the layout process that were confusing
people from time to time (based on the JIRA issues that were reported to
me):
https://blogs.oracle.com/jfxprg/entry/the_peculiarities_of_javafx_layout
(I'm sorry I never got to make part 2 :-( ).
Long Version:
I was looking into a layout issue in ControlsFX (BreadCrumbBar width is
reported incorrectly and it doesn't behave when right-aligned).
What I found is that Parent and SkinBase assume that layout has already
occurred on child nodes when computing the preferred width/height. The
JavaDocs indicate this is a known assumption:
* Calculates the preferred width of this {@code SkinBase}. The
default
* implementation calculates this width as the width of the area
occupied
* by its managed children when they are positioned at their
* current positions at their preferred widths.
Parent.computePrefWidth(double height) javadocs contain the exact same
comment.
Note however that the Region class documents
Region.computePrefWidth(double
height) differently. It simply states:
* Computes the preferred width of this region for the given height.
* Region subclasses should override this method to return an
appropriate
* value based on their content and layout strategy. If the subclass
* doesn't have a VERTICAL content bias, then the height parameter
can
be
* ignored.
Node.prefWidth(double height), which is what
Control.computePrefWidth(double height) delegates to if there is no
SkinBase, clearly states:
Returns the node's preferred width for use in layout calculations.
It's the for use in layout calculations part, combined with the fact
that
prefWidth relies on the layout having already happened, that confuses me.
Clearly layout is working in most cases, so this must all work out in the
general case. But as I understand it layout happens top-down, so
constraints imposed by the parent container must be accounted for when
positioning and sizing the children. That implies that the child nodes
are
not yet laid out when their preferred size is queried.
I fixed the issues I was having with BreadCrumbBar by overriding the
implementation of computePrefWidth(double height) with one that does not
care about the current X position of the child Nodes. It still relies on
the layout bounds via Node.prefWidth(double height), and duplicates some
of
the calculations that an actual layout will do, but it worked to solve the
problems of right-aligned layout and a widthProperty that was clearly
lying.
I feel like I am missing something fundamental about how Layout works
though.
Is there documentation that explains the general layout algorithm and how
to make sense of the apparent circular dependency?
The way it should work is that pref* min* max* methods
should be able to compute the layout without the layout actually
happening. This is basically a kind-of 2-pass top-down layout:
take a root (or any other parent in a tree) you want to layout. First, the
computation of size hints happens (and might be traversing down the tree).
After this stage, you know the size hints of the root's children, but no
layout happened yet.
Now the layout happens and the children are given their sizes (which might
not be equal to pref size), the layout is done recursively on the children
(now they know their final size they have all the information).
Theoretically, you could even cache the size hints in your skins (until
some of their prerequisites change) and use them at any stage of the layout
pass, even as the parent's sizes change during the
[8u60] Code Review Request For RT-30193: PrismSettings minTextureSize does not work
Hi Jim and Kevin, Please review this fix: JIRA: https://javafx-jira.kenai.com/browse/RT-30193 Webrev: http://cr.openjdk.java.net/~ckyang/RT-30193/webrev.00/ Thanks, - Chien
[8u60] review request: RT-39702: [SWT] No possibility to select text in FX content by using mouse dragging
Anton, Please review: https://javafx-jira.kenai.com/browse/RT-39702 http://cr.openjdk.java.net/~kcr/RT-39702/webrev.00/ Thanks. -- Kevin
