JDK-6235443 : REG:Overlapping a swing app with an AWT app causes flickering in the background swing app on Windows
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6,6u10,6u12
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: windows,windows_xp
  • CPU: generic,x86
  • Submitted: 2005-03-03
  • Updated: 2017-05-19
  • Resolved: 2011-05-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.
7 b36Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Overlapping a swing app with an AWT app causes flickering in the background swing app on Windows.

Steps to reproduce: 
1)Unjar the two attached test cases
2)On a windows system, run Swing app first (JFrameDec), Maximize it. 
3)Run the AWT App (FileDlgTest)
4)Move the AWT window to the center of the swing JFrame. 
5)Now try selecting the text from textarea in AWT window or try clicking inside the textarea repeatedly. 

You will see lot of flickering happening in the swing app which is in the backgroud on Windows. 
You can also use bugster instead of the given swing app. 
This is not happening on tiger and I could also not reproduce it till Mustangb08. It is happening from 6.0b12 onwards till the current promoted build 6.0b25.

###@###.### 2005-03-03 10:33:20 GMT

SUGGESTED FIX --- old/src/windows/native/sun/windows/awt_TextArea.cpp 2008-07-14 18:24:45.000000000 +0400 +++ new/src/windows/native/sun/windows/awt_TextArea.cpp 2008-07-14 18:24:45.000000000 +0400 @@ -209,15 +209,13 @@ void AwtTextArea::EditSetSel(CHARRANGE &cr) { // Fix for 5003402: added restoring/hiding selection to enable automatic scrolling - LockWindowUpdate(GetHWnd()); SendMessage(EM_HIDESELECTION, FALSE, TRUE); SendMessage(EM_EXSETSEL, 0, reinterpret_cast<LPARAM>(&cr)); SendMessage(EM_HIDESELECTION, TRUE, TRUE); - // 6417581: LockWindowUpdate doesn't force expected drawing + // 6417581: force expected drawing if (IS_WINVISTA && cr.cpMin == cr.cpMax) { ::InvalidateRect(GetHWnd(), NULL, TRUE); } - LockWindowUpdate(NULL); } void AwtTextArea::EditGetSel(CHARRANGE &cr) { @@ -993,12 +991,10 @@ c->CheckLineSeparator(buffer); c->RemoveCR(buffer); // Fix for 5003402: added restoring/hiding selection to enable automatic scrolling - LockWindowUpdate(c->GetHWnd()); c->SendMessage(EM_HIDESELECTION, FALSE, TRUE); c->SendMessageW(EM_SETSEL, start, end); c->SendMessageW(EM_REPLACESEL, FALSE, (LPARAM)buffer); c->SendMessage(EM_HIDESELECTION, TRUE, TRUE); - LockWindowUpdate(NULL); delete[] buffer; }

EVALUATION The problem is only observed, when AWT TextArea is used in the test. I found the desktop flickering is caused by the call to LockWindowUpdate which is introduced by the fix for 5003402. Removing these calls eliminates the flickering, and at the same time doesn't brake the fix for 5003402.

EVALUATION On my xp box I don't even need to overlap windows to see this behavior. I launched the swing app first. Then launch the awt app and all other swing apps get repainted. The paint event is coming from awt. We're getting an expose event for the complete window bounds. Reassigning to AWT for further investigation. ###@###.### 2005-03-07 17:30:27 GMT Reproducible on Win32. Seems that there is an extra paint event generated but I haven't found where could it be. I'm adding an AWTEventListener on Toolkit but there is nothing strange with paint events. Native AWT system only transfers events from Windows and doesn't create new one. ###@###.### 2005-03-10 11:47:37 GMT