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
|
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
|
Java