JDK-6871485 : Performance optimization of the HW/LW Mixing
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2009-08-13
  • Updated: 2011-01-19
  • Resolved: 2009-08-20
Related Reports
Relates :  
JDK-6868255 - Requirements for correct operating of the HW/LW Mixing feature need to be specified
Relates :  
JDK-6778882 - InternalFrame within glass pane goes below a heavy weight component
Relates :  
JDK-6852592 - invalidate() must be smarter
Relates :  
JDK-4993545 - NativeInLightFixer adds asynchronousity
Relates :  
JDK-6826074 - JScrollPane does not revalidate the component hierarchy after scrolling
Description
Applications that use the HW/LW Mixing feature should validate their component hierarchies (see 6868255 for details). 

Every operation changing layout-related information (e.g. setBounds(), setVisible(), setFont(), etc.) invalidates the component hierarchy. However, the current implemetnation of the hw/lw mixing also triggers the mixing code when such operations occur.

If invalidation of the hierarchy happens before calling the mixing code, then the mixing code will immediately return, spending, however, some time figuring out if the mixing is really needed to be performed or not.

If invalidation happens after calling the mixing code, then the shapes of components will be anyway recalculated again when validation of the hierarchy happens. If they appear to be equal to what's been calculated when, say, the setBounds() method was invoked, nothing will happen. Otherwise, the updated shape will be re-installed to the component.

One may notice that in both cases there's code that gets executed but either results in almost no-op, or recalculates the shapes once more time anyway.

Thus, eliminating the unnecessary code we can improve the performance of GUI applications.
Comments
EVALUATION There's no reasonable solution to the performance problem. All options seem to be workarounds that do not cover general cases, which we consider unacceptable. Since the total average performance increase of the initial fix is just about 0.6%, fixing this seems unimportant now. The CR might be reopened if we find a better way to improve the performance of the HW/LW Mixing feature.
20-08-2009
EVALUATION It seems that due to the special nature of lightweight popups we still need to handle them somewhat specially. Off the top of my head, we could: 1. make the popup layer being always present in the LayerePane, and make the layer a validate root. This would prevent invalidate() from invalidating the whole hierarchy. 2. Still have the mixOnShowing() and mixOnHiding() as special cases specifically for popups. This is still not perfect becaus mixOnHiding() was not actually optimal - it always recalculated shapes from scratch. But we could rework the logic as well.
19-08-2009
EVALUATION It appears that the LWPopupMenu.java and LWComboBox.java tests may only be fixed by adding appropriate revalidate() calls to the javax.swing.PopupFactory (in the ContainerPopup.hide() and LightweightPopup.show()). This, however, slowsdown the popup menus SwingMark test by 38%. Also, due to the absense of a fix for the CR 6852592, a private isValidateRoot() method must be introduced in the Component class. The method must use the isInstanceOf() method to verify if the component is a JComponent, and then call its isValidateRoot() method. This also brings some insignificant performance degradation (~0.5%). It looks like the first issue with a 40% slowdown is unacceptable. Since we don't have a solution for this currently, we don't plan to fix it in a 6 update release.
19-08-2009
EVALUATION While in 6 we could simple comment out the mixOn...() calls, in 7 we can't do that. Not only are the mixing-related tasks executed by the methods, but the logic of the former NativeInLightFixer is substituted with them (see 4993545 for details.) So it seems that the calls need to be retained, but the logic of the methods may be greatly simplified that should improve the performance anyway.
18-08-2009
EVALUATION Due to 6868255, it is reasonable to only execute mixing-related operations on validating the component hierarchy. We only need the Component.mixOnValidating() method. The other methods (such as mixOnShowing(), mixOnReshaping(), etc) can safely be eliminated. Preliminary testing shows an average 0,6% performance gain when running the SwingMark performance test for 100 cycles (see the attached spreadsheet for details). It is expected that the gain might be greater for applications that actually use the hw/lw mixing, but unfortunately we don't have a performace test for that. Two test/java/awt/Mixing/ regression tests require changes to execute correctly: they indeed didn't validate the component hierarchy before. However, there are two tests which require some assistance from the Swing team: LWPopupMenu.java and LWComboBox.java. It looks like Swing needs to validate the component hierarchy uppon displaying lightweight popups. This is very similar to such CRs like 6778882 or 6826074.
13-08-2009