In Java 7 and 8 there is a bug in Swing menus that causes it to be slow when running an application remotely over X11 while other X11 applications are running. This issue was introduced in Java 7 and has never been fixed. Does anyone have any suggestions on a workaround. Using nxclient addresses this Swing menu issue, but introduces its own unwelcome issues.
The steps to reproduce the Swing menu issue are:
- run any X11 application locally with some activity
- log into a remote server using ssh -Y someserver
- execute any Java GUI application (e.g. jvisualvm) running Java 7 or 8
- select a menu and observe a several second delay in response
Just spent an entire day trying to solve the same issue. There's barely any info out there.
Local machines:
Linux FedoraCore 20, KDE desktop, NVIDIA GeForce 7300 LE
Linux FedoraCore 20, KDE desktop, NVIDIA GeForce GT 720
Running remote Java GUI over ssh, swing popups are extremely slow for PC2. Desktop freezes until popup appears. On the other hand, PC1 runs very fast/smooth, with no problems at all.
Turns out, in my case, the problem is that PC2 has 2 monitors. The closest bug report I could find is: JDK-8004103 : sun.awt.X11.XToolkit.getScreenInsets() may be very slow and it appears to be still open.
Temporary Workarounds:
In KDE, Disable second monitor, Launch Application, Enable second monitor
Work in Gnome Desktop (My Gnome environment not affected by this issue)
Launch remote Java app using Java 6 (Issue not present in Java6)
None of these are ideal workarounds, but considering that my Desktop freezes for 3-4 seconds every time I click on a menu item, they'll do for the time being.
I finally found much better workaround for this problem. When opening the SSH connection to the remote computer, set ForwardX11Trusted option to "no".
ssh -o ForwardX11Trusted=no -X user#host.domain
For me, opening a ComboBox reduced from ~14s to instantly. Unfortunately, I currently don't have any Java applications with Swing Menu installed on the server, but I think this should work for Menus too.
If you don't want to type that option every time, add the following line to ssh config file (/etc/ssh/ssh_config)
ForwardX11Trusted no
Well, there still doesn't seem to be much information out there on how to work around this problem and running an application via remote X11/xinerama makes it practically unusable. In particular, menu navigation takes an eternity. The work-around that we employed has 2 parts to it.
At the startup of your application call:
JPopupMenu.setDefaultLightWeightPopuEnable(false);
This will force the popups to use heavy weight popups. Lightweight popups make multiple calls to the X windows across the network to determine what is visible, obscurred, etc. When operating over remote X11 this becomes a very expensive call. Lightweight popups make these calls everytime the popup becomes visible. Heavyweight popups make this call when they are 1st invoked, but every successive popup action reuses the heavyweight component that I'm guessing is managed by the window manager so the menus thereafter are very responsive.
Create a new XineramaJMenu class that extends JMenu. This class must override the method:
protected Point getPopupMenuOrigin()
{...}
copy the code for this method from JMenu, but replace the line:
Insets screenInsets = toolkit.getScreenInsets(gc);
with
Insets screenInsets = new Insets(0,0,0,0);
This eliminates the getScreenInsets(...) call, which makes multiple calls to the remote X server to determine the max inset values of the child windows. We eliminate this expensive call across the network and accept a default 0 inset.
Unfortunately, this will require you to replace all instances of JMenu with XineramaJMenu, but it at least results in usable menus when running your application over remote X11.
I was able to solve this problem on a RHEL 7 system with NVidia graphics board and NVidia driver 340.96 running KDE 4.14.8 by adding this option to the Screen section of the X server config file.
Option "nvidiaXineramaInfo" "Off"
The NVidia driver manual has this to say about this option:
The NVIDIA X driver normally provides a Xinerama extension that X
clients (such as window managers) can use to discover the current
layout of display devices within an X screen. Some window mangers get
confused by this information, so this option is provided to disable
this behavior.
Perhaps KDE is one of the window managers that gets confused?
Related
I am making use of JavaFX's built in Alert and Dialog classes which work great in Windows and when running from Eclipse within Windows, but appear behind the parent window when running on my target hardware which is running RedHat 6. I have tried tweaking various things including:
primaryStage.initStyle(StageStyle.UNDECORATED);
primaryStage.setFullScreen(true);
alert.initOwner(primaryStage) and alert.initOwner(primaryStage.getOwner())
alert.initModality(Modality.WINDOW_MODAL) and alert.initModality(Modality.APPLICATION_MODAL)
alert.initStyle(StageStyle.***) with *** being all possible styles.
The only way I have been able to get the alerts and dialogs to remain on top is by calling alert.initStyle(StageStyle.UTILITY) however this creates a window with a cross button which I do not want. Ideally I would prefer a bordered window without additional buttons, or an undecorated window which I should then be able to style to achieve the bordered look.
I have read of similar issues in which using Windows doesn't work but Ubuntu does. I haven't been able to find any open issues or solutions in this case.
I am using Java 8 Update 77.
I have experienced a similar problem: Alerts would show perfectly well in front of the primary stage in Windows 10, yet behind the stage when running the program on Ubuntu. alert.initOwner(primaryStage) actually solved the problem for me.
We have a Java based with some native components and SWT as frontend.
We contribute our tray icon to windows notification area.
Now below is the problem
If an user is working on the application and then the system goes to sleep/hibernate
When the system wakes up it has multiple tray icons for the same application.
We have seen it happening for multiple applications. Is it a known issue or are there any workarounds ?
Regards,
Saurav
I remember this happening in Windows XP. It's not a new things and has been around for years. I suspect it's a known issue but very low priority and so has never been addressed.
I remember it happening where the software that shows the icon doesn't shut down properly and so the icon it added doesn't get cleared up. You end up with multiple icons where multiple instances of the app have been started but not shut down correctly.
The real solution here would therefore seem to be to build more resilient software that doesn't crash. Obviously debugging hibernation issues can be tricky but I'd start by looking at your own software.
I have a legacy Java application that uses Java 1.3
It works fine on windows Xp but now I need to make it run on windows 7.
I have installed the 1.3 jdk however when it first loads, the app won't render properly. Bits of the screen just show grey background, selecting buttons won't load a new screen etc.
I do know watching the output from the app it just purely graphics not rendering properly.
However if I press "Ctrl-alt-delete" and then just press "cancel" the software runs perfectly.
If I have a second monitor plugged in, it runs perfectly.
Has anyone got any suggestions how to make app run perfectly first time.
Thanks
Firstly, update your java, no excuses not to.
You can try the hack of resizing your component to a different size and then back again. I find this is the best way to make sure that swing doesn't do this sort of mischief with black squares here and there.
These things happen from time to time with non native tools for desktop development as opposed to those specifically designed for the targeted platform.
I have a Java 7 application which is using Java Chromium Embedded Framework to draw html/css into two windows it launches. This works quite well in 4 of 5 PCs that I've run it on. In one case there are alignment issues with the rendered html. Successful runs include Windows 7/8/8.1. Unsuccessful run is 8.1 on an HP TouchSmart Envy, straight out of the box. Perhaps the only distinguishable differences are that this PC is new and that it has a touch screen.
As you can see, the content is shifted upward while being additionally clipped at the right and bottom sides. This is true of both windows that the application opens. What's even stranger is that mouse events (such as the :hover effects on the buttons and click events) are received in their correct position -- clicking about two inches below "Start Presentation" fires the button's click event.
Frankly, I have no idea what to try next on this. I've tried installing and uninstalling graphics-related software, adjusting the screen resolution, adding and removing the second screen, restarting the pc, and updating the onboard graphics driver.
As I have no idea what else could be causing this inconsistency, any advice in troubleshooting this issue would be fantastic.
As it turns out, this appeared to be related to the way JCEF interacts with system drivers. Going through Windows Update for the first time, restarting, and returning to the device's native resolution solved this issue.
Have a Java Swing app that is running on a Linux server and is being X displayed back via X11 forwarding. Cygwin is running on my workstation. Connection is made to the server using PuTTY with X11 forwarding and then ssh -XY .
Application launches just fine, but certain GUI elements (mostly drop down menus) do not behave correctly. Some menus close immediately after they are opened (the blink open/close when clicked.) Others will not select / highlight items using the mouse. Others will select different items than the one hovered over by my house.
The application works just fine on Windows or on Linux when invoked directed. Problem seems specifically related to viewing it through X11.
Is it possible X11 is swallowing some GUI events or not repainting fast enough?
This questions seems quiet old but I just had the same issue.
A solution may be to use compression (-C) and an other algorithm (which is faster) for the connection (-c cipher1, cipher2).
Eg. :
ssh -X -C -c blowfish-cbc,arcfour username#host
Hope it helps