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.
Short history of problem:
After upgrading to Ubuntu 15.10 I had some problems with any Qt-apps after durable work with IntellijIDEA. In apps like tortoisehg I saw painting problems, like not filled areas or shifted text. It was fixed after reading post in archlinux forum. Just set up property for Qt and changed my openjdk to oracle's.
The next story, that possibly is relative to first, consists in my work in IntellijIDEA and other Java swing applications (like Netbeans RCP): after long term working some dialogs became transparent, were inaccessible or just clicked through it to something under. Reopen of the dialog or window helps, but my colleagues have same problems on other OS, like Fedora (with KDE).
This bug is annoying, because our product is written on Netbeans and works under *nix distributive. Sometimes we stuck with problem of click-through problem: dialog or window just clicked into window after it.
I think the problem in wrong settings of x-server and in Qt- and Java- toolkit clash. This leads to artifacts on both application groups.
Does anybody stuck with this problem and do you have some ideas to resolve it?
The possible reason is described in Russian here (https://toster.ru/q/267833?e=3090918#clarification_329784).
Some bugs of it are found in:
https://bugs.kde.org/show_bug.cgi?id=350976
https://bugs.launchpad.net/ubuntu/+source/openjdk-7/+bug/1512760
Summary: the Java and Qt applications use shmem that is never cleaned by Java, after some time Qt cannot use this memory to work right. Google it with words «Java Qt shmem».
I want to play a video in frame using Java code in LUbuntu.
Till now I have used JMF and VLCJ framework for playing a video, it works absolutely fine on windows but not on Linux (It gives me FATAL error if I use VLCJ even for the same code which runs on windows and JMF doesn't get install on linux-ubuntu).
I have used 32 bit Linux and 1.8 JDK. Is there compatibility issue with Linux drivers and JMF drivers ?
But now I am trying to run via any script that will enable me playing a video on a frame not on browser.
It will be great if you give me proper guidance.
Thank you.
vlcj currently will not work on 32-bit Ubuntu, at least not without some nasty workarounds.
In fact, this will fail even if you do not use vlcj, if you write the code yourself without using vlcj you are guaranteed to see the same failure.
The issue is caused by some combination of Java, VLC, LUA and 32-bit Ubuntu.
Probably the simplest workaround is to delete the VLC LUA scripts, but that will disable some functionality (such as YouTube).
There is a lot of background information here, way too much to reproduce in this answer:
https://github.com/caprica/vlcj/issues/62
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?
I'm working on a Java program that is intended to run in full-screen mode. It uses numerous of customized Swing components and Java2D-drawn components that need to be updated and repainted several times a second. And it was working relatively fine on my underpowered work PC.
But then I tried it out at home on my much more powerful PC. And it ran noticeably slower. Triggering an event that should have instantly updated about 20 different screen elements instead caused an effect where each element seemed to take at least a quarter second each to repaint itself. So instead of instantaneous changes it was taking 5 seconds to complete each screen change.
I thought that maybe I was trying to repaint too often or in the wrong manner. But after experimenting a bit with other ideas, on a hunch I let the application start up in a windowed mode instead of in full-screen mode. And with that one change, everything started to work perfectly fast and smooth.
So I suppose there are really two issues here: Why does full-screen mode cause this problem? And why is it only causing this problem on my faster computer? I do suspect there's an OS-related bug. My slow work computer is Windows XP while the home one is Windows 7. I saw in other threads that Aero on Win7 can cause Java speed issues so I tried disabling it. That did cause a small speed improvement but it still wasn't as smooth as when I ran in windowed mode. Has anyone else had performance issues running full-screen Java apps on Win7? And if so, is there a work around?
I found the solution. I stumbled upon Oracle's Java System properties page (http://docs.oracle.com/javase/1.5.0/docs/guide/2d/flags.html) and figured there might be something useful there. While using the trace command I noticed that there were a lot of Direct3D references. Since nothing in my app is 3D, I thought that strange. So I added -Dsun.java2d.d3d=false to my Java command line. As the page says that option will "turn off the Java 2D system's use of Direct3D". And it worked like a charm. Now it runs perfectly smoothly on my Windows 7 machine in full screen mode.