Fwd: Re: API REVIEW for TabPane tab content loading and fixed content size

[Paru Somashekar]

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.somashekar at oracle.com>
To: 	Richard Bair <richard.bair at 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.somashekar at 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