JDK-5027400 : Creating UI with WindowsLookAndFeel is slow
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2004-04-06
  • Updated: 2005-01-25
  • Resolved: 2005-01-25
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6Resolved
Related Reports
Relates :  
JDK-5106661 - XP L&F does not work on Windows Vista (Longhorn) - needs to use uxtheme api
Relates :  
JDK-4795932 - RFE: Java 2D should locate fonts by using the windows registry
Relates :  
JDK-4990399 - JDWP: JFrame construction performance regression over 1.4.2 (method entry err?)
Description
An application that uses native look and feel needs longer time to start because building of its UI and painting is slower than with metal look and feel.

I measured time to create main window and paint it on a simple app that mimics NetBeans UI - menu hierarchy, toolbar icons, status line and currently empty main desktop area. Results on P4 2GHz, 1GB, WinXP consistently show the difference.

With default L&F and JDK1.4.2_03 times for warm start of this app are 961, 972, 961ms.
With WindowsLookAndFeel and JDK1.4.2_03 times for warm start of this app are 1222, 1242, 1252ms.
With default L&F and JDK1.5.0b39 times for warm start of this app are 1072, 1081, 1082ms.
With WindowsLookAndFeel and JDK1.5.0b39 times for warm start of this app are 1473, 1472, 1482ms.

###@###.### 2004-04-06
Comments
EVALUATION Name: sh120115 Date: 04/07/2004 This bug complains that startup with WindowsLookAndFeel is slower than with MetalLookAndFeel. I'm not sure that we can ever completely resolve this as there is more work to be done when starting the WindowsLookAndFeel. For one, there's a bunch of desktop properties that must be loaded. One item of note here though is the difference the submitter reports between 1.4.2 and 1.5.0. This is something that can likely be addressed. ###@###.### 2004-04-07 ====================================================================== 4795932 implemented a fix for mustang that on 1.7GHz P4 can reduce start-up time of the Windows L&F by up to 0.25 seconds. That may largely if not totally eradicate the difference. So it would be interesting to compare the test case in this report with that fix, but it seems difficult to build both 'ant' and netbeans fail to build the netbeans test case complaining : Compiler Adapter '${platforms.Java_HotSpot_TM__Client_VM_1.5.0-beta2-b39.compiler}' can't be found. This message is seen even when building with that version. It would be helpful if the submitter could attach step by step instructions on how to build the test case. ###@###.### 2004-08-20 ============================ The submitter supplied an updated test case whoch requires tiger or later. I've attached it to the bug report as fakeNetbeans2.zip (or I will once bugtraq starts co-operating with me). I build it with ant 1.6.2 (an earlier version failed) I ran the created jar file using the command java -cp fakeNetbeans.jar netbeans.fake.MyNetBeans [-winlf] I believe the time we are expected to compare against is the time for "creating" in the output. I ran it with 2 locally installed JRE's, which are our group nightly builds. One from the night before the fix(14th May), one from the night after the fix (17th May). This is the ONLY change. The impact of the fix is going to be system-specific affected by overall system performance and the number of fonts installed. I ran it on a 1.7Ghz P4 Xeon DELL system with 256MB RAM, and Windows XP Professional SP2. This system has all locale fonts installed and SP2 installs a few additional fonts, so this should show up an improvement if any were to be had, since the fix helps prevent loading all fonts on the system. Here are the results (times in milliseconds) L&F BEFORE FIX AFTER FIX DIFFERENCE METAL 1000,1015,1031 1000,1015,1031 <unchanged> WINLF 1453,1469,1484 1219,1235,1240 average of 237ms improvement There is still some unavoidable extra work in this case, as for the rest of the Windows L&F, but this fix mitigates almost exactly 50% of the difference. There also seems to be a small footprint benefit. Task Manager doesn't seem to be at all consistent but there was a repeatable benefit of > 200K to the fix. ###@###.### 2004-08-23 ============================ I have attached latest version of testcase from Radim. Looks like the UxTheme fix for WindowsLookAndFeel makes a huge difference and makes the performance same as Ocean. Below are the numbers with Ocean and Windows XP L&F : Ocean 1.5 : 1 Time 719 creating 719 1099611364187 1099611364906 2 Time 813 pack 94 1099611364906 1099611365000 3 Time 828 show 15 1099611365000 1099611365015 4 Time 875 addDirtyRegion 0, 0, 28, 28, javax.swing.JButton 5 Time 875 paintDirtyRegions took0 Windows 1.5 1 Time 1000 creating 1000 1099611384781 1099611385781 2 Time 1078 pack 78 1099611385781 1099611385859 3 Time 1094 show 16 1099611385859 1099611385875 4 Time 1109 paintDirtyRegions took0 So, yes, WindowsL&F seems slower to create in 1.5 : Here is Mustang with UxTheme : Ocean (1.6) : 1 Time 719 creating 719 1099611531718 1099611532437 2 Time 813 pack 94 1099611532437 1099611532531 3 Time 828 show 15 1099611532531 1099611532546 4 Time 860 addDirtyRegion 0, 0, 28, 28, javax.swing.JButton 5 Time 875 paintDirtyRegions took15 Windows (1.6) (UxTheme) 1 Time 750 creating 750 1099611557046 1099611557796 2 Time 829 pack 79 1099611557796 1099611557875 3 Time 844 show 15 1099611557875 1099611557890 4 Time 875 paintDirtyRegions took0 See http://bt2ws.central.sun.com/CrPrint?id=5106661 for more info of UxTheme fix. ###@###.### 11/4/04 23:49 GMT I've retested this with Mustang b20, and the results remain positive: OCEAN: [java] 1 Time 531 creating 531 1106684957406 1106684957937 [java] 2 Time 578 pack 47 1106684957937 1106684957984 [java] 3 Time 578 show 0 1106684957984 1106684957984 [java] 4 Time 594 paintDirtyRegions took0 WINLAF: [java] 1 Time 562 creating 562 1106684996250 1106684996812 [java] 2 Time 593 pack 31 1106684996812 1106684996843 [java] 3 Time 609 show 16 1106684996843 1106684996859 [java] 4 Time 609 paintDirtyRegions took0 I'm closing this out as no longer reproducible. ###@###.### 2005-1-25 20:36:59 GMT
25-01-2005
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mustang
24-09-2004