Bug ID: JDK-6768230 HW/LW mixing code slows down resize performance

Versions (Unresolved/Resolved/Fixed)

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	JDK 7
6u12 b02Fixed	7Fixed

Ancestor resized of HierarchyBoundsListener , should trigger on the components when the container is resized, but in 6u12 pit b01 build this event is not triggered. It works fine 6u10 b33 build. Hence its a regression introduced in this pit build.   

Step to reproduced:-
--------------------
1) Run the automated testcase.
java -DresultsDir=. HierarchyBoundsListenerTest.
Observed failures on the console. If you see the same then the bug is reproduced.

SUGGESTED FIX http://sa.sfbay.sun.com/projects/awt_data/6u12/6768230/
18-12-2008
EVALUATION The testcase attached to 6769531 reveals another problem with the HW/LW mixing code upon resize. When the user resizes the top-level, the reshape method of the Component class initiates the mixing upon reshape. The reshape method expects that the component has valid bounds updated on the event dispatched thread only but in some circumstances the bounds could be invalid because AWT native code also updates the bounds through JNI on the toolkit thread (AwtComponent::WmSizing function).
20-11-2008
EVALUATION AwtComponent::_SetRectangularShape calls Win32 API ::SetWindowRgn function, commenting out the ::SetWindowRgn call solves the performance issue, MSDN says: "When this function is called, the system sends the WM_WINDOWPOSCHANGING and WM_WINDOWPOSCHANGED messages to the window." So it looks like the root cause of the issue is that the native system generates too many messages when the mixing code works. The mixing code applies the shapes to the h/w components and currently the code works always, even if the new shape of the h/w component equals to the shape applied previouly (or normal shape). Applying new shape only if it's really different from the shape applied previouly (or normal shape) fixes the performance issue.
13-11-2008
EVALUATION The issue is a performance regression of the mixing feature. When the user resizes the top-level window, AWT gets a lot of resize events. Then, the mixing code starts to apply current shape to all h/w descendants of the container as a result of the validation of the container. AwtComponent::_SetRectangularShape method is called multiple times to apply current shape (number of the method calls = number of the live-resize events * number of the h/w components). All these calls follow to decrease in performance.
07-11-2008

Relates :	JDK-6777370 - PIT : AWT components are not rendered correctly after resizing the JFrame.
Relates :	JDK-4811096 - Allow limited mixing of heavy and lightweight components
Relates :	JDK-6829858 - JInternalFrame is not redrawing heavyweight children properly
Relates :	JDK-6769531 - PIT : Panel is seen above the ScrollPane which contains the table when frame is resized
Relates :	JDK-6777655 - PIT :Three regression testcases of mixing of heavy wt & light wt components fails on 6u12 pit build
Relates :	JDK-6777348 - PIT : Internal frame menu goes behind AWT Canvas in 6u12 b02 pit build