JDK-4669873 : DnD on jdk1.4.x for Windows freezes app for couple of seconds.
  • Type: Bug
  • Status: Closed
  • Resolution: Fixed
  • Component: client-libs
  • Sub-Component: java.awt
  • Priority: P2
  • Affected Version: 1.4.0
  • OS: windows_nt
  • CPU: generic
  • Submit Date: 2002-04-17
  • Updated Date: 2002-06-14
  • Resolved Date: 2002-06-14
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 Availabitlity Release.

To download the current JDK release, click here.
1.4.1 rcFixed
Related Reports
Relates :  
Relates :  
It is experienced on jdk1.4.x for Windows only (on jdk1.3 for Windows it seems to be fine).

1) Doing DnD, i.e. dragging component in application on windows using jdk1.4.x, above drop targets and outside drop target borders, occasionally freezes the app. During that time CPU is 100% used, app gives no responses, it takes usually about 5 sec, but were experienced cases up to 82 seconds.

2) On Netbeans it is possible to experience this issue very often, probably it has something to do with the amount of events run in the app. But event on testcase, which is comparing to NB trivial no event handling is done, it is possible to experience the problem. Note: it is experienced neither on jdk for Linux nor Solaris.

3) Testcase. It is possible to experience too. But you have to be more patient. 
Do following:
a) Repeat quickly to drag the component from tree, it seems to, you have to do quick motions, and go also outside the panel, provide the drop to the right area. Do more attempts in the row, sometime above the 10 are necessary to get the problem.
b) Sometimes you get the problematic state, it was experienced on windows jdk1.4.0-fcs, and 1.4.1-b08, but it wasn't on jdk1.3.1_03.
c) The problem is on NB it is seen much more easier, thus making the feature not usable.

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.0_03 hopper-rc FIXED IN: hopper-rc INTEGRATED IN: hopper-rc VERIFIED IN: hopper-rc

PUBLIC COMMENTS verified in java version "1.4.1-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-rc-b15) Java HotSpot(TM) Client VM (build 1.4.1-rc-b15, mixed mode) ###@###.### 2002-06-14 --------------------------------------------------------

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