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.

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?

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?

Thanks
Richard

Reply via email to