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'.

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.

 xxxxx@xxxxx  2002-10-04

Commit to fix in Merlin (regression).  
 xxxxx@xxxxx  2000-10-03




 xxxxx@xxxxx 

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?
 xxxxx@xxxxx  2001-01-22




 xxxxx@xxxxx 

The problem with grabage under mouse cursor can be workarounded by setting sun.java2d.noddraw flag to true at start.


======================================================================



commit to hopper and tiger
======================================================================




 xxxxx@xxxxx  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.

 xxxxx@xxxxx  2002-10-04

Workaround in eval does not help applets targeting the plug-
in because we cannot ask clients to goto JPI control panel & 
enter -Dsun.java2d.noddraw=true !  Applet deployers *really* 
need per-applet control of this property (until 2D can promise 
fault-free ddraw rendering on all desktops:).

I agree 100% with cforster.  There are a number of 
workarounds in this category that sound well and good for 
server apps, but make no sense for applets intended to be 
used by hundreds of end users that have no knowledge of 
Java -- and don't want any either, especially of the "Java is 
the thing I have to reconfigure to no end on my desktop to 
make it function".

The ddraw UI "tearing" bug fits into this category.  Java 2 
v1.4's inclusion of a broken Xalan (one which throws security 
exceptions if used from an applet) is another prime example 
[there is another JDC bug on this].

As an applet deployer (or even worse, an applet developer 
selling to multiple deployers), we can't tell end users to "edit 
ddraw...", find a working Xalan and put it in 
{JRE}/lib/endorsed, and....  It has to work immediately as 
deployed...

What vm release is mantis?  When is it scheduled?

"Mantis" is the name for J2SE 1.4.2. Regards, Nick.

Oh, I forgot: It is scheduled for release in the beginning of 
2003. See http://java.sun.com/features/2002/03/totiger.html
Nick.