United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-8024858 : Tooltip freezes entire application

Details
Type:
Bug
Submit Date:
2013-09-12
Status:
Resolved
Updated Date:
2017-02-11
Project Name:
JDK
Resolved Date:
2015-06-08
Component:
client-libs
OS:
windows_7
Sub-Component:
java.awt
CPU:
Priority:
P3
Resolution:
External
Affected Versions:
7u40
Fixed Versions:
9

Related Reports
Duplicate:
Relates:
Relates:
Relates:

Sub Tasks

Description
FULL PRODUCT VERSION :
java version "1.7.0_40"
Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601]

EXTRA RELEVANT SYSTEM CONFIGURATION :
Multi-monitor setup, NVIDIA Quadro FX 770M

A DESCRIPTION OF THE PROBLEM :
At the first time a tooltip should show up in a Swing application, the application freezes. The duration of the freeze depends on the number of screen devices. For example in a dual screen environment the freeze time gets doubled.

After a short investigation the method getDrawingGC() in class TooltipManager causes this problem. At the first time this method gets called, each call to GraphicsDevice.getConfigurations() hangs about 5 or more seconds. In Java 7 Update 25 and earlier versions the call of this method takes less than 100 ms.

It seems to be caused by JDK-7123767 which was fixed in update 40.

This bug is even reproducible without the TooltipManager as shown in the source code of the executable test case.


REGRESSION.  Last worked in version 7u25

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
The issue can be reproduced with any java application.
For example the button demo in the Java tutorials also show this behaivor (http://docs.oracle.com/javase/tutorial/uiswing/examples/components/index.html#ButtonDemo).

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
  Tooltip should not freeze application.
ACTUAL -
Application freezes imediatelly for about 10 seconds in dual screen environment.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
public class Test
{

public static void main(String[] args)
{
long startTime = System.currentTimeMillis();
GraphicsEnvironment env = GraphicsEnvironment.getLocalGraphicsEnvironment();
GraphicsDevice devices[] = env.getScreenDevices();
for (GraphicsDevice device : devices)
{
device.getConfigurations();
System.out.println(device);
}

System.out.println(String.format("Consumed time: %d ms", System.currentTimeMillis() - startTime));
}
}
---------- END SOURCE ----------
                                    

Comments
We have reproduced a similar issue when creation of Win32GraphicsDevice takes abnormally long time.

Unfortunately, it is not clear whether there are any common roots, because in our case the slowness seems to be caused by an issue in a driver of a virtual graphics adapter. However, in our case explicit forcing of D3D pipeline (-Dsun.java2d.d3d=True) makes the problem gone.
                                     
2016-09-07
Changed resolution to External since the problem is in video drivers.
                                     
2015-06-08
This problem is caused by a peculiarity in a particular version of NV drivers.
An upgrade the driver makes the problem gone.
                                     
2015-04-27
 - this is an issue reported against 7(7u),
 - there are now affected version 9 filed for this issue
 - 7u issues are transferred to Sustaining
Nevertheless if someone have a report against 9 - please reopen and add affectedVersion 9
or
7u specific escalations might be reopen to Sustaining
                                     
2014-08-10
 - this is an issue reported against 7(7u),
 - there are now affected version 9 filed for this issue
 - 7u issues are transferred to Sustaining
Nevertheless if someone have a report against 9 - please reopen and add affectedVersion 9
or
7u specific escalations might be reopen to Sustaining
                                     
2014-08-10
RT NOTE:
Approved. Check on known issue + release note for tool tip issue.
                                     
2013-10-11
RT NOTE:

Client (bulk)

The criteria for deferral bulk request bugs:
- Not P2
- Not tck-red
- Not critical to customer

Approved.
                                     
2013-10-11
jdk8: SQE OK to defer
                                     
2013-10-10
8-client-defer-candidate: The problem is hardware specific, we cannot reproduce it even with the help from the sqe team.
                                     
2013-10-10
Possibly as a workaround the initial fix can be reworked. Or an additional information needed from the submitter about graphics api slowness. profiler snapshots/build where a regression in grapics was introduced/etc.
                                     
2013-09-24



Hardware and Software, Engineered to Work Together