SUGGESTED FIX
Name: dsR10078 Date: 06/04/2002
Call WaitMessage if there are no messages of the two selected types on
the queue. Call GetQueueStatus after WaitMessage returns to mark all
unread messages on the queue as old messages.
The secondary message pump uses selective PeekMessage that retrieves
messages of only two types and if there are some other messages on the
queue they will be always considered unread. So, if we don't call
GetQueueStatus to mark them as old, WaitMessage will always return
immediatelly and drag freezes will still manifest.
--- awt_DataTransferer.cpp Mon Jun 3 20:46:06 2002
***************
*** 212,218 ****
static VOID CALLBACK
IdleFunc() {
! /* do nothing */
}
static BOOL CALLBACK
--- 212,219 ----
static VOID CALLBACK
IdleFunc() {
! ::WaitMessage();
! ::GetQueueStatus(QS_ALLINPUT);
}
static BOOL CALLBACK
###@###.### 2002-06-04
======================================================================
|
EVALUATION
Evaluation:
I was unable to reproduce the bug on WinNT and Win2000 with the
attached test case. The problem readily manifests on Netbeans
development build 200204230100 running on Win2000 SP2 5.10.2195
with 1.4.1-b10. Here are the possible steps to reproduce:
1)Install and configure Netbeans to run in MDI mode.
2)Run Netbeans with -J-Dnetbeans.winsys.dnd=true.
3)When Netbeans starts up and the main window is displayed there will
be a tabbed pane with four tabs: Editing, GUI Editing, Running,
Debugging. Make sure the Editing tab is selected.
4)You should see another tabbed pane with four tabs: Runtime,
Filesystems, Project default, Javadoc. Click on either of these four
tabs. The selected tab should receive focus.
5)Then press the left mouse button on the selected tab and drag the
mouse over Netbeans panes. Some panes will provide a drag-under
feedback.
6)As the mouse is dragged over these panes, the drag freezes will
manifest. The symptom is that the drag-under feedback is not
provided. The freezes are typically 5-10 seconds long, but can take
up to 3 minutes depending on the environment.
The investigation shows that in my environment long freezes (more than
10 seconds) manifest only if either the Netbeans or the JRE are on a
network drive accessed via the Reflection NFS Client or the Client for
Microsoft Networks. The cause is that some WinNTFileSystem methods are
very slow when the file is accessed over the network. In my environment
a single call to canonicalize(), getBooleanAttributes(),
getLastModifiedTime() can last for 10-20 (and up to 200) seconds. If
this slowdown happens during a drag operation it manifests as a long
drag freeze.
When both the Netbeans build and the JRE are on the local drive the
drag freezes still manifest, but they are not so long - typically 5-10
seconds.
A typical stack trace of the java event dispatch thread at the
point of freeze in WinNTFileSystem is attached to this bug report as
edt-dump.txt.
The time profiling of the java event dispatch thread indicates that
in most cases drag freezes while a
SystemEventQueueUtilities.ComponentWorkRequest is processed.
Typically ComponentWorkRequest processing takes less than 100
milliseconds, but sometimes it takes significant time: 3-7 seconds and
it manifests as a drag freeze. Other events never take more than 100
milliseconds.
For time profiling of the java event dispatch thread I applied
the patch attached to this bug report as EventDispatchThread.java.pch
to the file src/share/classes/java/awt/EventDispatchThread.java.
ComponentWorkRequest is posted to the java event queue to repaint all
Swing components that are marked as "dirty". For time profiling of the
painting code I applied the patches attached to this bug report as
SunGraphics2D.java.pch and GraphicsPrimitives.java.pch to
src/share/classes/sun/java2d/SunGraphics2D.java and
src/share/classes/sun/java2d/loops/GraphicsPrimitives.java
respectively.
Painting code profiling shows that in most cases slow processing of a
ComponentWorkRequest can be tracked to one of the three cases:
1)Slow execution of SunGraphics2D methods caused by slowdown in a
DirectDraw graphics primitive. The excerpt from the Netbeans log
that demonstrates this situation is attached to the bug report as
ide1.log.
The Netbeans was run with the following additional options:
-J-Dnetbeans.winsys.dnd=true
-J-Dsun.java2d.trace=log,timestamp
2)Slow execution of SunGraphics2D methods not related to graphics
primitives. The profiling indicates that typically SunGraphics2D
methods take less than 100ms, but occasionally they execute very
slowly: up to 3-4 seconds.
Here are the peak results for several methods:
SunGraphics2D.fillRect - 3936 milliseconds
SunGraphics2D.drawImage(Image,int,int,Color,ImageObserver)
- 4036 milliseconds
SunGraphics2D.constrain - 3835 milliseconds
SunGraphics2D.makeFontMetrics - 3986 milliseconds
SunGraphics2D.drawRect - 4436 milliseconds
SunGraphics2D.transformShape(int,int,Shape)
- 3315 milliseconds
SunGraphics2D.clone - 3986 milliseconds
SunGraphics2D.create - 3655 milliseconds
This situation manifests more readily when DirectDraw is disabled.
It is demonstrated by ide3.log
The Netbeans was run with the following additional options:
-J-Dnetbeans.winsys.dnd=true
-J-Dsun.java2d.trace=log,timestamp
-J-Dsun.java2d.noddraw=true
3)Slow execution of Swing painting code that is not tracked down to
a single SunGraphics2D method.
This situation manifests more readily when DirectDraw is disabled.
It is demonstrated by ide2.log and ide3.log.
The Netbeans was run with the following additional options:
-J-Dnetbeans.winsys.dnd=true
-J-Dsun.java2d.trace=log,timestamp
-J-Dsun.java2d.noddraw=true
The machine used for profiling has Matrox Millenium G450 DualHead,
driver version 5.72.21.0.
###@###.### 2002-05-07
Danila has requested reassigning this to 2D. If more investigation is needed
by Drag&Drop and AWT, please let us know.
###@###.### 2002-05-07
As per agreement with DnD group, reassigning the bug back to DnD.
###@###.### 2002-06-03
Name: dsR10078 Date: 06/04/2002
While a drag operation is in progress, the toolkit thread runs
secondary message pump that processes all sent messages, and posted
messages of two types: WM_PAINT messages and application-specific task
messages. This message pump is designed to call PeekMessage filtering
WM_PAINT and task messages in a tight loop. Although PeekMessage is
documented to yield at appropriate time, on Win2000 the secondary
message pump occasionally occupies all processor time that manifests
as drag freezes.
###@###.### 2002-06-04
======================================================================
This fix will be verified by the Forte group.
###@###.### 2002-06-06
|
Java
