As a follow up to the previous post that showed how LightBeam tool can be used to analyze the performance of various core and third-party Swing look-and-feels, today i’m going to answer Luke’s question in the comments section and compare the performance of the core Substance skins.
The table below lists all available core Substance skins, and three numbers for each skin. The first number is the average time to complete a static performance scenario (rendering a bunch of controls to an offscreen image). The second number is the heap size after the static performance scenarios have been completed. The third number is the total time to run all dynamic performance scenarios (the list can be found in the PDF report or in the source code).
There is a simple explanation why Magma, Office 2007 family and Raven family have 25-45% worse dynamic performance than the rest – they use watermarks. I have already mentioned that this has been identified as the biggest performance obstacle during the performance tuning of version 5.0dev, and the skins that used the simple translucent-fill watermark do not use any watermark at all. The selected skins mentioned above are still using non-null watermarks to provide better visuals. You can extend these skins and set the watermark field to null in the constructor to get better performance (but less distinct visuals).
As you can see, there are minimal differences in the rest of the skins, even though they use different button shapers and painters. The core button shapers and painters have been improved to provide uniform performance so that you don’t have to sacrifice the visuals for the performance (except, once again, the watermarks).
If you do find that your custom skin has distinctly different results under different painters, i would be very interested in hearing about this in the project forums, mailing lists or a private e-mail.
About a month ago i have introduced the new project named LightBeam that aims to assist look-and-feel writers to measure performance of their libraries under various static and dynamic scenarios. I have used this tool extensively during the performance optimizations of the next release of Substance look-and-feel, and it has now reached its first official release 1.0 code-named Antares.
The project distribution contains sample script files to test static and dynamic scenarios under the core look-and-feels (Metal, Windows and Nimbus), as well as a selection of active third-party look-and-feels (Substance, Looks and Synthetica). The performance spreadsheet available for download contains the breakdown of different scenarios, and here is the “executive summary” for the dynamic scenarios that try to emulate most common user interaction flows:
- 3,039 ms – Metal
- 3,721 ms – Windows
- 4,004 ms – Looks Plastic XP
- 4,696 ms – Nimbus
- 4,794 ms – Substance Autumn 5.0dev
- 4,908 ms – Synthetica default
- 13,146 ms – Substance Autumn 4.3
All the numbers are taken on my main development machine running the latest b26 of 6u10.
Supporting decoration areas and per-window skins in the next release of Substance look-and-feel required rewriting the skinning layer from the scratch. The current APIs represent my best understanding of skinning functionality at the present moment, and the internal implementation was heavily influenced by performance considerations. Applications that just used the bundled core Substance skins will not have to change their code. However, those applications that created custom Substance themes and skins will have to adjust the code to the new APIs.
As the old theming implementation continued evolving and getting new features, it quickly outgrew the original design and made adding new features progressively more difficult. Those of you who either looked at the code or used the old SubstanceTheme and SubstanceComplexTheme know what i’m talking about. I know that every time i had to add a new feature to an existing skin or create a new skin, i witnessed the “ugliness” of the theming API. As already mentioned, this has been completely rewritten in version 5 to address the following:
- Better modeling of logical structure of a UI skin
- Cleaner, more generic and more extensible implementation
- Performance, performance, performance
The main concepts in the new skinning layer of Substance 5 are:
- Color scheme – information to paint a single control in a specific visual state. For example, you can have one color scheme for rollover button, and another color scheme for pressed button.
- Color scheme bundle – information to paint all controls in a specific decoration area. Allows registering color schemes and alpha values for different component states, as well as registering highlight and border color schemes for different component states.
- Skin – information to paint a top-level window (with all its decoration areas). Allows specifying supported decoration areas, registering color scheme bundles for different decoration areas, registering a watermark and watermark color scheme, setting painters (border, gradient, decoration and highlight) and a few miscellaneous settings.
The following documentation has been updated to reflect the latest stable drop of 5.0dev:
Here are some sample screenshots from the documentation of 5.0dev:
If you have been waiting to try the 5.0dev branch, now is the time. The main functionality that i wanted to see is in, and the APIs should be stable enough with only minor changes projected based on user feedback. If you wrote a custom pre-5.0 skin, i will gladly assist in porting it to the new API. If you have any questions on the new APIs, or have any suggestions on the existing documentation, let me know. The official release is planned for early September. The earlier you try, the more chances i will have to address your feedback.
Note that documentation for the latest stable release 4.3 is available with the full distribution archive (and in CVS tagged with release_4_3_06_nairobi). Version 4.3 is in long term support stage. Please consult the updated release info notes to see the list of backported bug fixes.
A considerable part of the new skinning layer of Substance is geared towards enabling writing Swing applications that have UI capabilities of this WPF application designed by frog studio (mentioned a few months ago on this blog):
The required changes have slowly sipped into releases 4.2 and 4.3 of Substance, but were limited due to maintaining as much backwards compatibility as possible. However, the old skinning / theming layer was not up to the challenge, especially considering its deficiencies in handling mixed light / dark skins. This layer has been completely rewritten in version 5.0 (currently under development) and it is now possible to use different skins for different top-level windows (such as frames and dialogs).
To specify a custom skin for the specific top-level window, use the SubstanceLookAndFeel.SKIN_PROPERTY client property and set it on the root pane of that window. To get the skin of the specific control (to provide custom painting that is consistent with how Substance paints core and third-party Swing components), use the SubstanceLookAndFeel.getCurrentSkin(Component) API.
Here is a screenshot that shows an application with twelve top-level frames, each using its own skin (click for the fullsize version):
Note that applications using a single global skin do not incur performance overhead. Applications that use per-window skins do not incur performance overhead as well, but the memory consumption will be higher due to a larger number of cached images.
You’re more than welcome to test the latest development drop of Substance 5 and report any bugs (visual or exceptions) to the project mailing lists, forums on in a private e-mail.
