Bug ID: 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

JDK 11	JDK 12	JDK 8
11.0.2Fixed	12 b14Fixed	8u192Fixed

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

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.
25-10-2018
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
10-09-2018
JMH results: Before: ToolkitPerf.testGetScreenInsets 0.142 ops/ms After: ToolkitPerf.testGetScreenInsets 11.421 ops/ms
10-09-2018
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.
10-09-2018
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
10-09-2018
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.
06-09-2018
[~serb] please look at the latest update in bugDB
05-09-2018
Caused by JDK-4737732
05-09-2018
Seems to be duplicate of awt issue JDK-8004103
30-08-2018
does it affect 9?
22-06-2017

Duplicate :	JDK-8004103 - sun.awt.X11.XToolkit.getScreenInsets() may be very slow
Relates :	JDK-8134669 - Empty screen insets in Gnome 3, OEL 7 in multiscreen mode
Relates :	JDK-8252349 - Delete the "sun.awt.X11.checkSTRUT" property
Relates :	JDK-4737732 - Toolkit.getScreenInsets() doesn't work on Linux/GNOME
Relates :	JDK-8004103 - sun.awt.X11.XToolkit.getScreenInsets() may be very slow