Re: Re: API REVIEW for TabPane tab content loading and fixed content size
On Mon, Jul 8, 2013 at 5:31 PM, Paru Somashekar < parvathi.somashe...@oracle.com> wrote: > > 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). Does that mean there is currently a bug computing the correct preferred size because the CSS values for the unselected tabs is not taken into account? I personally would not bother optimizing this if it is simply a fact that "doing the right thing" to compute the correct preferred size takes longer simply because there are more nodes to layout. The optimizations suggested are all hacks that ultimately result in incorrect results in my opinion. If I wanted that level of control I would code my app to add the content to the selected tab upon selection rather than over-complicating the API of the TabPane. You time is better spent fixing broken stuff. Scott
Fwd: Re: API REVIEW for TabPane tab content loading and fixed content size
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 To: Richard Bair 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 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
Re: API REVIEW for TabPane tab content loading and fixed content size
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 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
Re: API REVIEW for TabPane tab content loading and fixed content size
Hi Daniel,
I took all your suggestions and have made the changes, and below is the
updated API for the policy as well as the updated notes for performance
considerations. In particular I have made the change to talk about
"adding" the content of a tab to the scene graph vs loading the content
of the tab and also highlighted the performance gains and caveats.
thanks,
Paru.
TabContentSceneGraphPolicy is a static enum within TabPane
public static enum TabContentSceneGraphPolicy {
// The content all the tabs are added to the scenegraph up front
with no optimization. If there are a lot of tabs and content is large -
this could potentially cause slow start up time. This is the default
behavior.
ALL_TABS,
//Only the content of the selected tab will be added to
the scenegraph on startup and other tabs get added on selection. When a
new tab is selected, its content is added into the scenegraph and the
content of the previously selected tab is removed from the scenegraph.
SELECTED_TAB_AND_REMOVE,
//Only the content of the selected tab will be added to
the scenegraph on startup and other tabs get added on selection. Once
added, a Tab is kept in the scenegraph. When a new tab is selected for
the first time, its content is added into the scenegraph. Subsequent
selection will result in faster tab switch time as the content is
already part of the scenegraph.
SELECTED_TAB_AND_KEEP
//Only the content of the selected tab will be added to
the scenegraph at startup and content of other tabs
get added asynchronously in the background. Hence there is
no adding and removing of tab content when different tabs are selected
as in the case of the SELECTED_TAB options.
ALL_TABS_ASYNCH,
}
Notes on performance considerations
The TabPane offers some performance optimizations in the area of adding
the tab content to the scene graph. Basically the default policy is to
add the contents of all specified tabs to the scenegraph upfront. If the
TabPane consists of a large number of big content tabs, then this could
lead to a potential slow start up time, as it will have to spend some
time in adding all the content up front before starting up.
In such situations, the TabPane allows specification of the
TabContentSceneGraphPolicy which determines how the tab contents are
added : all tabs, selected tab and remove, selected tab and keep and
selected tab and asynchronous addition of other tabs.
"All tabs" is the default policy, where all the content is added to the
scenegraph upfront as stated above and it suffers from slow start up time.
The "selected tab and remove " policy adds the content of the selected
tab to the scenegraph and adds the contents of other tabs "lazily" on
selection, resulting in quicker startup time than the default polcy. It
also ensures that content of the previously selected tab is removed from
the scenegraph. This gives the added benefit of ensuring that no
scenegraph related activities are performed on any of the tab contents
that is not currently selected. However this could potentially cause the
tab switch operation to be a bit slow.
The "selected tab and keep" policy offers a slight variation compared to
the above policy in that, instead of removing the content of the
previously selected tab, it is kept around once added. This results in
faster tab switch operation for subsequent tab selections after the
first time a tab is selected.
The fourth policy, "all tabs asynch", handles adding the content of the
rest of the tabs asynchronously in the background after initially adding
the content of the selected tab on startup. However this option could
result in a slower runtime performance.
Another area of optimization is provided for specifying a fixed width /
height / size of the tab content area. If a fixed value is specified,
measurement of the tab content sizes for the purpose of setting the
available space is eliminated, thus providing faster resize operations
on windows that contain a TabPane in them.
-
On 7/3/13 3:23 PM, Daniel Zwolenski wrote:
I'd probably be a little cautious about the term 'loading' then. In
particular, I'd probably read 'LAZY_LOADING' to hint that the actual
tabs themselves would be loaded/created lazily (a common use case).
Might be just me though.
It looks like the 'lazy' option actually does them eagerly (i.e. all
on startup - not so lazy :) ), just asynchronously. I wonder if there
is a need for one that does them truly 'lazily' (i.e. on selection)
much like the SELECTED_TAB but once first loaded it then keeps it
there instead of adding and removing each selection.
Maybe not the best names below but some ideas:
enum TabContentSceneGraphPolicy {
// The content all the tabs are *added* to the scenegraph up
front with n
Re: API REVIEW for TabPane tab content loading and fixed content size
I'd probably be a little cautious about the term 'loading' then. In
particular, I'd probably read 'LAZY_LOADING' to hint that the actual tabs
themselves would be loaded/created lazily (a common use case). Might be
just me though.
It looks like the 'lazy' option actually does them eagerly (i.e. all on
startup - not so lazy :) ), just asynchronously. I wonder if there is a
need for one that does them truly 'lazily' (i.e. on selection) much like
the SELECTED_TAB but once first loaded it then keeps it there instead of
adding and removing each selection.
Maybe not the best names below but some ideas:
enum TabContentSceneGraphPolicy {
// The content all the tabs are *added* to the scenegraph up front
with no optimization. If there are a lot of tabs and content is large -
this could potentially cause slow start up time. This is the default
behavior.
ALL_TABS,
//Only the content of the selected tab will be *added* to the
scenegraph at startup and content of other tabs get *added* *asynchronously* in
the background. Hence there is no *adding* and *removing* of tab content
when different tabs are selected as in the case of the SELECTED_TAB options.
ALL_TABS_ASYNCH,
//Only the content of the selected tab will be *added to the **
scenegraph* on startup and other tabs get *added* on selection. When a new
tab is selected, its content is *added* into the scenegraph and the content
of the previously selected tab is *removed* from the scenegraph.
SELECTED_TAB_AND_REMOVE,
//Only the content of the selected tab will be *added to the **
scenegraph* on startup and other tabs get *added* on selection. Once added,
a Tab is kept in the scenegraph. When a new tab is selected for the first
time, its content is *added* into the scenegraph, after that the tab is
re-shown when selected again.
SELECTED_TAB_AND_KEEP
}
On Thu, Jul 4, 2013 at 8:06 AM, Paru Somashekar <
parvathi.somashe...@oracle.com> wrote:
> **
> Hi Daniel,
>
> Yes, loading is referring to when the tab content gets added to the scene.
> The API to add tabs to TabPane remain the same - the new API is only
> proposing a policy that controls how they get added & removed from the
> scenegraph.
>
> thanks,
> Paru.
>
>
> On 7/3/13 2:35 PM, Daniel Zwolenski wrote:
>
> Hi Paru,
>
> What do you mean by 'loaded'?
>
> Currently we create the tabs and then manually add them doing something
> like:
>
> TabPane tabPane = new TabPane();
> tabPane.getTabs().add(new Tab("Tab1"));
>
> Wouldn't all the 'loading' have already happened before TabPane gets a
> look in? Or are you talking about when the tabs get added to the scene?
>
> Cheers,
> Dan
>
>
>
>
> On Thu, Jul 4, 2013 at 7:03 AM, Paru Somashekar <
> parvathi.somashe...@oracle.com> wrote:
>
>
> JIRA : https://javafx-jira.kenai.com/
> browse/RT-24105&
> https://javafx-jira.kenai.com/
> browse/RT-30648
>
> The following is API to control how tab content gets loaded for a TabPane
> in order to improve startup time and runtime performance for a TabPane.
>
> Jonathan has already reviewed the following API and I have incorporated
> his feedback. Thanks Jonathan.
>
> TabContentSceneGraphPolicy is a static enum within TabPane
> -- --
> public static enum TabContentSceneGraphPolicy {
> //The content all the tabs get loaded up front with no
> optimization. If there are a lot of tabs and content is large - this could
> potentially cause slow start up time. This is the default behavior.
> ALL_TABS,
> //Only the content of the selected tab will be loaded on startup
> and other tabs get loaded on selection. When a new tab is selected, its
> content is loaded into the scenegraph and the content of the previously
> selected tab is unloaded from the scenegraph.
> SELECTED_TAB,
> //Only the content of the selected tab will be loaded at startup
> and content of other tabs get loaded lazily in the background. Hence there
> is no loading and unloading of tab content when different tabs are selected
> as in the case of SELECTED_TAB option.
> SELECTED_TAB_WITH_LAZY_LOADING
> }
> -- -- --
> API to specify fixed Width/Height/Size for tab content.
>
> private DoubleProperty fixedWidth
> public final void setFixedWidth(double value)
> public final double getFixedWidth()
> public final DoubleProperty fixedWidthProperty()
>
> private DoubleProperty fixedHeight
> public final void setFixedHeight(double value)
> public final double getFixedHeight()
> public final DoubleProperty fixedHeightProperty()
>
> public final void setFixedSize(double width, double height)
> -- --
> Notes on performance considerations
>
> The TabPane offers some performance optimiz
Re: API REVIEW for TabPane tab content loading and fixed content size
Hi Daniel,
Yes, loading is referring to when the tab content gets added to the
scene. The API to add tabs to TabPane remain the same - the new API is
only proposing a policy that controls how they get added & removed from
the scenegraph.
thanks,
Paru.
On 7/3/13 2:35 PM, Daniel Zwolenski wrote:
Hi Paru,
What do you mean by 'loaded'?
Currently we create the tabs and then manually add them doing
something like:
TabPane tabPane = new TabPane();
tabPane.getTabs().add(new Tab("Tab1"));
Wouldn't all the 'loading' have already happened before TabPane gets a
look in? Or are you talking about when the tabs get added to the scene?
Cheers,
Dan
On Thu, Jul 4, 2013 at 7:03 AM, Paru Somashekar
> wrote:
JIRA : https://javafx-jira.kenai.com/ browse/RT-24105
&
https://javafx-jira.kenai.com/ browse/RT-30648
The following is API to control how tab content gets loaded for a
TabPane in order to improve startup time and runtime performance
for a TabPane.
Jonathan has already reviewed the following API and I have
incorporated his feedback. Thanks Jonathan.
TabContentSceneGraphPolicy is a static enum within TabPane
-- --
public static enum TabContentSceneGraphPolicy {
//The content all the tabs get loaded up front with no
optimization. If there are a lot of tabs and content is large -
this could potentially cause slow start up time. This is the
default behavior.
ALL_TABS,
//Only the content of the selected tab will be loaded on
startup and other tabs get loaded on selection. When a new tab is
selected, its content is loaded into the scenegraph and the
content of the previously selected tab is unloaded from the
scenegraph.
SELECTED_TAB,
//Only the content of the selected tab will be loaded at
startup and content of other tabs get loaded lazily in the
background. Hence there is no loading and unloading of tab content
when different tabs are selected as in the case of SELECTED_TAB
option.
SELECTED_TAB_WITH_LAZY_LOADING
}
-- -- --
API to specify fixed Width/Height/Size for tab content.
private DoubleProperty fixedWidth
public final void setFixedWidth(double value)
public final double getFixedWidth()
public final DoubleProperty fixedWidthProperty()
private DoubleProperty fixedHeight
public final void setFixedHeight(double value)
public final double getFixedHeight()
public final DoubleProperty fixedHeightProperty()
public final void setFixedSize(double width, double height)
-- --
Notes on performance considerations
The TabPane offers some performance optimizations in the area of
tab content loading. Basically the default policy is to load the
contents of all specified tabs. If the TabPane consists of a large
number of big content tabs, then this could lead to a potential
slow start up time, as it will have to spend some time in loading
all the content up front before starting up.
In such situations, the TabPane allows specification of the
TabContentSceneGraphPolicy which determines how the tab contents
are loaded : all tabs, selected tab only, or selected tab and lazy
loading of the rest of the tabs. The selected tab only option also
ensures the content of the previously selected tab is removed from
the scenegraph. This gives the added benefit of ensuring that no
scenegraph related activities are performed on any of the tab
contents that is not currently selected. However this could
potentially cause the tab switch operation to be a bit slow. In
order to achieve faster tab switch operation, the third option is
provided where the content of the rest of the tabs are loaded
lazily in the background. However the lazy loading option could
result in a slower runtime performance.
Another area of optimization is provided for specifying a fixed
width / height / size of the tab content area. If a fixed value is
specified, measurement of the tab content sizes for the purpose of
setting the available space is eliminated, thus providing faster
resize operations on windows that contain a TabPane in them.
-- -- ---
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) measu
Re: API REVIEW for TabPane tab content loading and fixed content size
Hi Paru,
What do you mean by 'loaded'?
Currently we create the tabs and then manually add them doing something
like:
TabPane tabPane = new TabPane();
tabPane.getTabs().add(new Tab("Tab1"));
Wouldn't all the 'loading' have already happened before TabPane gets a look
in? Or are you talking about when the tabs get added to the scene?
Cheers,
Dan
On Thu, Jul 4, 2013 at 7:03 AM, Paru Somashekar <
parvathi.somashe...@oracle.com> wrote:
>
> JIRA :
> https://javafx-jira.kenai.com/**browse/RT-24105&
> https://javafx-jira.kenai.com/**browse/RT-30648
>
> The following is API to control how tab content gets loaded for a TabPane
> in order to improve startup time and runtime performance for a TabPane.
>
> Jonathan has already reviewed the following API and I have incorporated
> his feedback. Thanks Jonathan.
>
> TabContentSceneGraphPolicy is a static enum within TabPane
> --**--
> public static enum TabContentSceneGraphPolicy {
> //The content all the tabs get loaded up front with no
> optimization. If there are a lot of tabs and content is large - this could
> potentially cause slow start up time. This is the default behavior.
> ALL_TABS,
> //Only the content of the selected tab will be loaded on startup
> and other tabs get loaded on selection. When a new tab is selected, its
> content is loaded into the scenegraph and the content of the previously
> selected tab is unloaded from the scenegraph.
> SELECTED_TAB,
> //Only the content of the selected tab will be loaded at startup
> and content of other tabs get loaded lazily in the background. Hence there
> is no loading and unloading of tab content when different tabs are selected
> as in the case of SELECTED_TAB option.
> SELECTED_TAB_WITH_LAZY_LOADING
> }
> --**--**--
> API to specify fixed Width/Height/Size for tab content.
>
> private DoubleProperty fixedWidth
> public final void setFixedWidth(double value)
> public final double getFixedWidth()
> public final DoubleProperty fixedWidthProperty()
>
> private DoubleProperty fixedHeight
> public final void setFixedHeight(double value)
> public final double getFixedHeight()
> public final DoubleProperty fixedHeightProperty()
>
> public final void setFixedSize(double width, double height)
> --**--**
> Notes on performance considerations
>
> The TabPane offers some performance optimizations in the area of tab
> content loading. Basically the default policy is to load the contents of
> all specified tabs. If the TabPane consists of a large number of big
> content tabs, then this could lead to a potential slow start up time, as it
> will have to spend some time in loading all the content up front before
> starting up.
>
> In such situations, the TabPane allows specification of the
> TabContentSceneGraphPolicy which determines how the tab contents are loaded
> : all tabs, selected tab only, or selected tab and lazy loading of the rest
> of the tabs. The selected tab only option also ensures the content of the
> previously selected tab is removed from the scenegraph. This gives the
> added benefit of ensuring that no scenegraph related activities are
> performed on any of the tab contents that is not currently selected.
> However this could potentially cause the tab switch operation to be a bit
> slow. In order to achieve faster tab switch operation, the third option is
> provided where the content of the rest of the tabs are loaded lazily in the
> background. However the lazy loading option could result in a slower
> runtime performance.
>
> Another area of optimization is provided for specifying a fixed width /
> height / size of the tab content area. If a fixed value is specified,
> measurement of the tab content sizes for the purpose of setting the
> available space is eliminated, thus providing faster resize operations on
> windows that contain a TabPane in them.
> --**--**---
>
> 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.
>
API REVIEW for TabPane tab content loading and fixed content size
JIRA : https://javafx-jira.kenai.com/browse/RT-24105 &
https://javafx-jira.kenai.com/browse/RT-30648
The following is API to control how tab content gets loaded for a
TabPane in order to improve startup time and runtime performance for a
TabPane.
Jonathan has already reviewed the following API and I have incorporated
his feedback. Thanks Jonathan.
TabContentSceneGraphPolicy is a static enum within TabPane
public static enum TabContentSceneGraphPolicy {
//The content all the tabs get loaded up front with no
optimization. If there are a lot of tabs and content is large - this
could potentially cause slow start up time. This is the default behavior.
ALL_TABS,
//Only the content of the selected tab will be loaded on
startup and other tabs get loaded on selection. When a new tab is
selected, its content is loaded into the scenegraph and the content of
the previously selected tab is unloaded from the scenegraph.
SELECTED_TAB,
//Only the content of the selected tab will be loaded at
startup and content of other tabs get loaded lazily in the background.
Hence there is no loading and unloading of tab content when different
tabs are selected as in the case of SELECTED_TAB option.
SELECTED_TAB_WITH_LAZY_LOADING
}
--
API to specify fixed Width/Height/Size for tab content.
private DoubleProperty fixedWidth
public final void setFixedWidth(double value)
public final double getFixedWidth()
public final DoubleProperty fixedWidthProperty()
private DoubleProperty fixedHeight
public final void setFixedHeight(double value)
public final double getFixedHeight()
public final DoubleProperty fixedHeightProperty()
public final void setFixedSize(double width, double height)
Notes on performance considerations
The TabPane offers some performance optimizations in the area of tab
content loading. Basically the default policy is to load the contents of
all specified tabs. If the TabPane consists of a large number of big
content tabs, then this could lead to a potential slow start up time, as
it will have to spend some time in loading all the content up front
before starting up.
In such situations, the TabPane allows specification of the
TabContentSceneGraphPolicy which determines how the tab contents are
loaded : all tabs, selected tab only, or selected tab and lazy loading
of the rest of the tabs. The selected tab only option also ensures the
content of the previously selected tab is removed from the scenegraph.
This gives the added benefit of ensuring that no scenegraph related
activities are performed on any of the tab contents that is not
currently selected. However this could potentially cause the tab switch
operation to be a bit slow. In order to achieve faster tab switch
operation, the third option is provided where the content of the rest of
the tabs are loaded lazily in the background. However the lazy loading
option could result in a slower runtime performance.
Another area of optimization is provided for specifying a fixed width /
height / size of the tab content area. If a fixed value is specified,
measurement of the tab content sizes for the purpose of setting the
available space is eliminated, thus providing faster resize operations
on windows that contain a TabPane in them.
---
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.
