-
Bug
-
Resolution: Fixed
-
P1
-
6u14
-
b03
-
generic
-
generic
-
Verified
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-2173305 | 7 | Peter Zhelezniakov | P3 | Resolved | Fixed | b72 |
| JDK-2184380 | OpenJDK6 | Peter Zhelezniakov | P3 | Resolved | Fixed | b18 |
It was shown that avoiding Nimbus initialization saves about 10% of startup of simple FX apps.
E.g. here are data from Dmitry's experiment:
> In the meantime, the difference between initializing Nimbus L&F and not during startup is about 11% on my system for FXFramer: 2.24s vs 2.0s .
This is significant chunk of time. Expecially because many FX applications barely need Nibmus as they do not use standard Swing components.
There are some efforts to delay nimbus initialization on FX side. But these are workarounds and it will be always possible to defeat them. Nimbus startup has to be optimized.
E.g. here are data from Dmitry's experiment:
> In the meantime, the difference between initializing Nimbus L&F and not during startup is about 11% on my system for FXFramer: 2.24s vs 2.0s .
This is significant chunk of time. Expecially because many FX applications barely need Nibmus as they do not use standard Swing components.
There are some efforts to delay nimbus initialization on FX side. But these are workarounds and it will be always possible to defeat them. Nimbus startup has to be optimized.
- backported by
-
JDK-2173305 Nimbus initialization is too slow
-
- Resolved
-
-
-
- Resolved
-
- relates to
-
JDK-6797730 Umbrella: Applet startup performance improvements
-
- Closed
-
-
-
- Closed
-