JDK-4475369 : Using heavyweight over lightweight components we see unacceptable flashing
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.3.1
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_nt
  • CPU: x86
  • Submitted: 2001-06-27
  • Updated: 2002-05-07
  • Resolved: 2001-10-17
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.
Other Other Other
1.3.0_05 05Fixed 1.3.1_03Fixed 1.4.0Fixed
Related Reports
Relates :  
JDK-5091604 - Swing applications paint grey rectangles before actual content gets painted
Relates :  
JDK-4295524 - Swing popup menus cause Canvas3D to flash
Relates :  
JDK-4221190 - Frame back ground being erased with default color , What if we don't need erase
Relates :  
JDK-4673900 - Switching between panels leaves the old panel displayed the new one.
Relates :  
JDK-4419252 - Expose events being incorrectly generated
Relates :  
JDK-4692074 - Regression - painting problem introduced in 1.3.1_03 patch release
Relates :  
JDK-4479178 - RFE: Support for Transparent windows required
Description
When both placing and removing Heavyweight "peer" components over Lightweight Swing components we are experiencing an unacceptable flash on the screen.  This note describes our application's design intent, our application's problem and our analysis of the cause.  A small but illustrative sample program is included with a narrative.
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.3.0_05 1.3.1_03 merlin-beta3 FIXED IN: 1.3.0_05 1.3.1_03 merlin-rc1 INTEGRATED IN: 1.3.0_05 1.3.1_03 merlin-rc1
14-06-2004
SUGGESTED FIX ###@###.### 2001-10-05 Fixed for windows platform only. Integrated in 1.3.0_05. src/win32/classes/sun/awt/windows/WCanvasPeer.java src/win32/native/sun/windows/awt_Canvas.cpp ------- WCanvasPeer.java ------- *** /tmp/dFpaqMn Wed Sep 26 09:54:18 2001 --- WCanvasPeer.java Fri Sep 21 17:32:44 2001 *************** *** 19,24 **** --- 19,33 ---- class WCanvasPeer extends WComponentPeer implements CanvasPeer, DrawingSurface { + private static boolean eraseBackgroundDisabled; + + static { + String noerasebackground = (String)java.security.AccessController.doPrivileged( + new sun.security.action.GetPropertyAction("sun.awt.noerasebackground")); + eraseBackgroundDisabled = (noerasebackground != null + && noerasebackground.length() > 0 + && noerasebackground.charAt(0) == 't'); + } // Toolkit & peer internals *************** *** 80,83 **** --- 89,96 ---- public DrawingSurfaceInfo getDrawingSurfaceInfo() { return new WDrawingSurfaceInfo(this); } + + public boolean shouldClearRectBeforePaint() { + return (eraseBackgroundDisabled == false); + } } ------- awt_Canvas.cpp ------- *** /tmp/dstayNn Wed Sep 26 09:55:20 2001 --- awt_Canvas.cpp Fri Sep 21 14:08:12 2001 *************** *** 129,135 **** CATCH_BAD_ALLOC_RET(0); } - /* * This routine is duplicated in AwtWindow. */ --- 129,134 ---- *************** *** 136,145 **** MsgRouting AwtCanvas::WmEraseBkgnd(HDC hDC, BOOL& didErase) { m_eraseBackground = TRUE; - didErase = TRUE; - RECT rc; - ::GetClipBox(hDC, &rc); - ::FillRect(hDC, &rc, this->GetBackgroundBrush()); return mrConsume; } --- 135,140 ----
11-06-2004
EVALUATION Moving to incomplete as attached code does not match comments sections. scott.violet@eng 2001-06-28 Submitter has attached correct version and is now reproducible. I believe all of the painting is happening in the native/awt side. The flash of yellow and flash of red don't appear to be coming from the Swing side of things (nor do they appear to be coming from paint/update on the Canvas). I'm reassigning to AWT for further investigation. scott.violet@eng 2001-06-28 This is probably due to the following code in awt_Canvas.cpp /* * This routine is duplicated in AwtWindow. */ MsgRouting AwtCanvas::WmEraseBkgnd(HDC hDC, BOOL& didErase) { didErase = TRUE; RECT rc; ::GetClipBox(hDC, &rc); ::FillRect(hDC, &rc, this->GetBackgroundBrush()); return mrConsume; } It may require a new API if we want to allow developers to choose to suppress handling of WM_ERASEBKGND. See 4221190. See Comments. eric.hawkes@eng 2001-07-19 This same behavior can be seen on Solaris also. In order to fix this we would have to offer a transparent background. This is a proposed Tiger feature. See RFE: 4479178 richard.ray@eng 2001-07-25 Another note. This issue has nothing to do with lightweights. Both Jframe and Canvas are heavyweights. The same behavior can be seen with a simple java.awt.Frame application. The background will be filled with the background color whenever the heavyweight is displayed or invalidated. richard.ray@eng 2001-07-27 This has been escalated, so it can be addressed in the Merlin time-frame. My concern is the Win32 "fix" might be simple, but not so sure about X-Windows. richard.ray@eng 2001-07-31
27-07-2001