JDK-8170937 : Swing apps are slow if displaying from a remote source to many local displays
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 8u102,10.0.1,11,12
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2016-12-08
  • Updated: 2020-08-26
  • Resolved: 2018-09-19
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 Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 12 JDK 8
11.0.2Fixed 12 b14Fixed 8u192Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
sun.awt.X11.XToolkit.getScreenInsets() may be very slow  

Our configuration is Java 8u102 32bit running on RedHat 6.8 with the remote
X11 display on a RedHat 6.8 machine with 3 monitors.
Dropdown menus, and comboboxes are taking over 2 seconds to respond to mouse

Fix Request: It was escalated by customer and by the Netbeans, it affects performance of lots of applications on Unix in multi-screen configuration is enabled. Fix has been backported to 8u also. jdk12 patch applies cleanly to 11u.

At some point we need to support "_NET_WORKAREA_MONITORS" which is not standardized yet. https://github.com/mate-desktop/mate-panel/issues/303#issuecomment-417689098

JMH results: Before: ToolkitPerf.testGetScreenInsets 0.142 ops/ms After: ToolkitPerf.testGetScreenInsets 11.421 ops/ms

Note that the fix updates the logic which were added in the JDK-8134669, we should not use the bounds of the root window and _NET_WORKAREA directly, because rootBounds and _NET_WORKAREA are in the virtual global coordinate systems, but the insets should be related to bounds of specific graphics configuration.

Overall problem description: Most of operation systems provide some special places on the screen where applications should not place its windows. These places are called insets and used by the global menu, docks and system panels. The opposite place is called workarea. The X11 which is used on unix currently provide the rectangular area "_NET_WORKAREA", which does not work well in case of multi-screen configuration, especially when the dock/menu/panels are located in between of two monitors. We have tried to workaround it by using " _NET_WM_STRUT/_NET_WM_STRUT_PARTIAL", but unfortunately these hints for the applications. WM should take into account these hints when "_NET_WORKAREA" is calculated, but the system panels are not necessary contain these hints(Gnome 3 for example). Different libraries solve this bug in a different ways: QT: https://bugreports.qt.io/browse/QTBUG-18380 "Note, on X11 this will return the true available geometry only on systems with one monitor and if window manager has set _NET_WORKAREA atom. In all other cases this is equal to geometry()." GTK(SWT uses the same logic): https://code.woboq.org/gtk/gtk/gdk/x11/gdkmonitor-x11.c.html#69 The proposed fix: http://cr.openjdk.java.net/~serb/8170937/webrev.00 Note that the fix has one side effect, the tests w/o proper synchronization may fail because of our windows are opened instantly. The updated method is called during Window initialization: http://hg.openjdk.java.net/jdk/jdk/file/5a1be00ea4f6/src/java.desktop/share/classes/java/awt/Window.java#l518

Some numbers: Toolkit.getDefaultToolkit().getScreenInsets() - Default system(after login): 60 ops/sec - Default system(after login)+2000 windows: 3 ops/sec - Default system(after login)+2000 windows+ ssh -X to the same host: 0,5 ops/sec We spent 30% of the time in the XSync.

[~serb] please look at the latest update in bugDB

Caused by JDK-4737732

Seems to be duplicate of awt issue JDK-8004103

does it affect 9?