JDK-4374079 : Win32:Lightweight components do not immediately repaint in response to repaint()
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.0,1.4.1,1.4.2
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS:
    solaris_7,windows_95,windows_nt,windows_2000,windows_xp solaris_7,windows_95,windows_nt,windows_2000,windows_xp
  • CPU: x86,sparc
  • Submitted: 2000-09-26
  • Updated: 2002-12-18
  • Resolved: 2002-11-12
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
1.4.1_02 02Fixed 1.4.2Fixed
Related Reports
Duplicate :  
JDK-4702044 - GUI update problems with some demo applets on Win2000 an WinXP
Duplicate :  
JDK-4664490 - REGRESSION: AWT window background isn't drawn on win32 using javaw
Duplicate :  
JDK-4763268 - REGRESSION: 1.4 Repaint event is not handled in JRE when started with javaw.
Duplicate :  
JDK-4717086 - COMPATIBILITY: hopper-rc Hghlnd Golf applet fails to display graphics correctly
Duplicate :  
JDK-4458337 - Merlin: repaints do not work by using javaw on WinNT if double buffering is disa
Duplicate :  
JDK-4757919 - Paint error of panel in GraphicsTest applet
Duplicate :  
JDK-4615038 - started blank applet is transparency without entering the cursor
Duplicate :  
JDK-4587558 - Applet does not repaint background properly
Duplicate :  
JDK-4488406 - Selected cell in SpreadSheet demo repaints incorrectly
Duplicate :  
JDK-4628179 - REGRESSION: AWT applet background doesn't refresh correctly
Relates :  
JDK-4684615 - JCK1.4: api/java_awt/interactive/PrintDialogTest.html
Relates :  
JDK-4726491 - Painting is broken in some GS test windows on T. Chinese Win2K Pro
Description
To reproduce this bug, run the regression test located at 
test/java/awt/Focus/MixedWeightFocus. While this is indeed a focus regression
test, the bug does *not* appear to be a focus bug. It is reproducible in the
current Windows merlin promotion, even though the promotion does not contain
the new focus implementation.

In 'FocusFrame', focus 'button 1' by clicking on it. Then press TAB. A focus
rectangle should draw around 'lw 1'. That is the behavior in kestrel. However,
the rectangle will not draw until you move the mouse over 'lw 1'.
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: 1.4.1_02 mantis INTEGRATED IN: 1.4.1_02 mantis mantis-b07
14-06-2004
SUGGESTED FIX *** /tmp/vertlBAA9maGA5 Thu Oct 31 08:37:04 2002 --- /tmp/vertlCAA.maGA5 Thu Oct 31 08:37:04 2002 *************** *** 64,69 **** --- 64,72 ---- info->hDC = NULL; // Setting hDC to null will trigger init below info->clip = NULL; TlsSetValue(threadInfoIndex, (LPVOID)info); + DTRACE_PRINTLN2("0x%x: Win32SD::SetupTGI batch limit: %d\n", + GetCurrentThreadId(), ::GdiGetBatchLimit()); + ::GdiSetBatchLimit(1); } HDC hDC = info->hDC; if (hDC == NULL || (info->wsdo != wsdo)) { ###@###.### 2002-10-31
31-10-2002
WORK AROUND Programmatically, call Toolkit.sync(); or run the applet/application with java instead of javaw or appletviewer Use java sun.applet.AppletViewer *.html instead of appletviewer. ###@###.### 2002-10-04
04-10-2002
EVALUATION Commit to fix in Merlin (regression). eric.hawkes@eng 2000-10-03 Name: dmR10075 Date: 01/22/2001 ###@###.### I was unable to reproduce the bug as it was described in the report. I tried b35, b46, b47 on Win2000 and WinNT4.0. On Win2000 I've met the following behaviour: when you click over the lightweight from the test it receives the focus and redraws but the place under the mouse remains corrupted. Seems to be the 2D problem. ====================================================================== I am still able to reproduce the bug on merlin build 48 using Windows 2000 SP 1 on a dual-processor Dell 733 Pentium III. Can you retest using a dual-processor machine? david.mendenhall@east 2001-01-22 Name: dmR10075 Date: 01/23/2001 ###@###.### The problem with grabage under mouse cursor can be workarounded by setting sun.java2d.noddraw flag to true at start. ====================================================================== Name: rpR10076 Date: 11/16/2001 commit to hopper and tiger ====================================================================== Name: ssR10077 Date: 07/19/2002 ###@###.### 2002-07-19 The bug is reproducible on win2000 with Hopper b16. The same behavior is observed when running demo applets. For example with DitherTest if you shrink window horizontaly by dragging the border the controls aren't redrawn. If you move mouse cursor on the Panel, the image is fixed up. AWT doesn't redraw at this time. I suggest to recategorize the bug to java2d. ====================================================================== The problem is that Gdi batches our rendering requests but never executes them. If the application directly calls Toolkit.sync() (which calls ::GdiFlush()), the rendering appears as expected. Note that the problem is limited to javaw, appletviewer and browsers. Investigation reveals that for some reason the default number of requests GDI batches is different for appletviewer.exe, javaw.exe and java.exe. GdiGetBatchLimit reports: javaw, appletviewer: 20 java : 0 (which means 'default', whatever it is) This is most likely caused by the way these applications are created/compiled. For example, appletviewer.exe has batch limit 20, and the problem is clearly there, but if the same applet is run as java.exe sun.applet.AppletViewer *.html the reported limit is 0, and the problem doesn't appear. If the batch limit is set to 1 using GdiSetBatchLimit (disable batching), the problem goes away. Another note that supports this theory is that each thread has its own batch limit setting, so if the applet creates a new thread and issues rendering from that thread, it appears fine, even if run with appletviewer.exe. Continuing the investigation. ###@###.### 2002-10-04
04-10-2002