United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4669873 DnD on jdk1.4.x for Windows freezes app for couple of seconds.
JDK-4669873 : DnD on jdk1.4.x for Windows freezes app for couple of seconds.

Details
Type:
Bug
Submit Date:
2002-04-17
Status:
Closed
Updated Date:
2002-06-14
Project Name:
JDK
Resolved Date:
2002-06-14
Component:
client-libs
OS:
windows_nt
Sub-Component:
java.awt
CPU:
generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
1.4.0
Fixed Versions:
1.4.1 (rc)

Related Reports
Relates:
Relates:

Sub Tasks

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

                                    

Comments
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
======================================================================
                                     
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
                                     
2002-06-04
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
--------------------------------------------------------
                                     
2002-06-14
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


                                     
2004-06-14



Hardware and Software, Engineered to Work Together