United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4374079 Win32:Lightweight components do not immediately repaint in response to repaint()
JDK-4374079 : Win32:Lightweight components do not immediately repaint in response to repaint()

Details
Type:
Bug
Submit Date:
2000-09-26
Status:
Resolved
Updated Date:
2002-12-18
Project Name:
JDK
Resolved Date:
2002-11-12
Component:
client-libs
OS:
windows_nt,solaris_7,windows_xp,windows_95,windows_2000
Sub-Component:
2d
CPU:
x86,sparc
Priority:
P3
Resolution:
Fixed
Affected Versions:
1.4.0,1.4.1,1.4.2
Fixed Versions:
1.4.1_02 (02)

Related Reports
Backport:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Relates:
Relates:

Sub Tasks

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
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
                                     
2002-10-04
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
                                     
2002-10-04
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
                                     
2002-10-31
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


                                     
2004-06-14



Hardware and Software, Engineered to Work Together