forgot to do a replyall.
thanks,
Paru.
-------- Original Message --------
Subject: Re: API REVIEW for TabPane tab content loading and fixed
content size
Date: Mon, 08 Jul 2013 14:30:20 -0700
From: Paru Somashekar <parvathi.somashe...@oracle.com>
To: Richard Bair <richard.b...@oracle.com>
Hi Rich,
On 7/8/13 9:57 AM, Richard Bair wrote:
Hi Paru, I have a few questions. The first is, why does it make a difference
whether the tab content is added to the scene graph or not? If a node is marked
visible=false, it *should* be essentially the same as not being in the graph.
That entire branch shouldn't be picked, etc. I don't doubt that you are seeing
a performance difference, but I wonder whether the right answer is to fix the
places in the SG (if possible) that are causing this problem (perhaps, for
example, layout?) rather than adding an API which controls when the tab
contents are added to the SG.
When all of the content is added to the scene graph, the RESIZE TEST
part of the performance test suite showed lower fps as against when only
the selected tab's content was part of the scene graph. This is because
layout gets called for the tabs that are not currently selected /
visible. ( confirmed that CSS does not get called however for tabs not
visible).
In particular, we know we have a problem when it comes to computing the
preferred size of the TabPane.
On Jul 3, 2013, at 2:03 PM, Paru Somashekar<parvathi.somashe...@oracle.com>
wrote:
There might be a situation where the TabContentSceneGraphPolicy is set to
SELECTED_TAB in which case only the content of the selected tab is loaded and
user does not set fixed size. In such a case, we can either do one of the
following,
1) hardcode a fixed size if it is not already set
2) measure the selected tab only and grow in size only if the size of the next
selected tab is bigger than the previous one.
3) throw an exception if SELECTED_TAB is chosen and fixed size is not set.
I prefer option either 1 or 2, that way we do not force the developer to set a
fixed size for the tab content.
Thoughts suggestions welcome, I shall go with option 1 if I don't hear any.
This I think is the real question, how to deal with the pref size of a
TabPane? Right now, we will ask each tab for its pref size, and then take the
max pref width / pref height from the tabs, add on the tab pane insets etc and
return that. Is that correct? So is the large cost in adding the tab content to
the SG just that it is being included in these computations, or is there
something else?
Yes, it is just including these computations, nothing else as far as I
know.
I'm worried that the TabContentSceneGraphPolicy is going to exacerbate the
problem, because the pref size will change as tabs are changed and *by default*
this will probably lead to the tab pane changing its size on people (depending
on the layout container, but imagine an HBox or something for example).
One answer is backwards incompatible: change tabbed pane to have a hard-coded
pref size. Not a very nice answer. Another solution is to add an enum which
indicates how the tabbed pane should compute its pref size:
- based on the pref size of all tabs
- based on the pref size of the initial tab
- based on the pref size of the selected tab? Is this one useful?
And then always leave all tab content in the SG but just change how the pref
size is being computed. By default it is all tabs, but can be set to initial
tab or hard-coded by the developer?
Do we know why having tab pane content in the SG when it is not visible is a
performance problem?
I think if we fix ( potentially a layout bug) the issue of not calling
layout of tabs that arent't visible, (on operations like resize), then
we do not need to remove the content from the SG after lazy loading them.
Thanks
Richard
