-
Bug
-
Resolution: Cannot Reproduce
-
P4
-
None
-
7u40
By doing some profiling while using SceneBuilder I easily come to a case where when not interacting at all with SceneBuilder the average CPU consumed is 4 times the lower bound (which is when you start the tool on a blank layout).
Fact is between the two profiling snapshot the sole thread where we spend time doesn't contain anything from the SceneBuilder API, it's all about FX runtime.
Scenario to reproduce:
1. Get the latest promoted SceneBuilder (1.1 b12 runs over Java 7 U12 b02 + FX 2.2.6 b02)
2. Drop a SplitPane (dropping in Hierarchy or on Content doesn't matter, using a Vertical or Horizontal one doesn't matter either)
3. Drop a TableView in one of the two AnchorPane of the SplitPane
4. In Hierarchy panel (the one on bottom left) move the TableView under top component (then out of SplitPane)
The CPU drop from 4% to 16% and stays permanently at that level. I've reset profiling data at that point then took a second snapshot a few minutes later.
This occurs on all platforms (Linux, Mac, Windows). The attached profiling snapshots have been done on MacOS 10.8.2.
Note:
- I tried to use another control without reproducing the issue (tried ListView and Button).
- I tried using another container without reproducing the issue (tried StackPane)
That said the set of combinations is so big it's difficult to say at first the sole winning ouple is SplitPane + TableView.
Fact is between the two profiling snapshot the sole thread where we spend time doesn't contain anything from the SceneBuilder API, it's all about FX runtime.
Scenario to reproduce:
1. Get the latest promoted SceneBuilder (1.1 b12 runs over Java 7 U12 b02 + FX 2.2.6 b02)
2. Drop a SplitPane (dropping in Hierarchy or on Content doesn't matter, using a Vertical or Horizontal one doesn't matter either)
3. Drop a TableView in one of the two AnchorPane of the SplitPane
4. In Hierarchy panel (the one on bottom left) move the TableView under top component (then out of SplitPane)
The CPU drop from 4% to 16% and stays permanently at that level. I've reset profiling data at that point then took a second snapshot a few minutes later.
This occurs on all platforms (Linux, Mac, Windows). The attached profiling snapshots have been done on MacOS 10.8.2.
Note:
- I tried to use another control without reproducing the issue (tried ListView and Button).
- I tried using another container without reproducing the issue (tried StackPane)
That said the set of combinations is so big it's difficult to say at first the sole winning ouple is SplitPane + TableView.
- blocks
-
JDK-8122151 General performance issue in some cases
-
- Closed
-