Users of our application have been experiencing problems with their Swing GUIs not drawing correctly.
The common link between all users with problems is that they've recently applied a Windows update. Users have reported that dialogs draw correctly on some monitors but not on others.
An example of the kind of problems we're seeing*:
Users also report dialogs which only show a frame, and are otherwise transparent. Effectively the same kind of problems you'd see if the UI thread were blocked.
What could be the problem?
*I can't post screenshots of our actual application as it contains sensitive information
Update: This issue has been fixed in update KB4039884.
This seems to be a reasonably wide-spread issue caused by a recent patch. It's not limited to Java:
It seems, that Microsoft’s Update KB4034664 (and KB4034679) for
Windows 7 and Windows Server is causing display issues with several
applications on a second screen.
Reported by Born City, Computer World, and Microsoft themselves:
If a machine has more than one monitor connected and the screen
numbering is not in sequence, some applications will experience
rendering issues.
You should be able to solve the problem by rolling back the patch. It is a security update (links above detail what is included), so if you're particularly risk-averse you may not want to do this.
Microsoft lists the workaround as:
Enable Desktop Composition (needs graphics card support).
Make sure that the main monitor is on the top left in the monitor layout.
You could also try switching to a single monitor setup, or making other changes to your monitor configuration (Control Panel > Display > Change display settings). Some reports speculate that which monitor is set as your 'main display' may make a difference.
You might also want to try the following flag: -Dsun.noddraw=true
Related
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».
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 have an issue where the keys on my Type Cover 2 on my Surface Pro 2 gets stuck after holding them down for 8 seconds. This is particularly annoying with to ctrl/shift/alt keys which often end up being held for a long time when editing images and so forth.
The solution to the problem is to disable "Microsoft Input Configuration Device" in Device Manager, however, it as well has some drawbacks, as most of the touchpad gestures will no longer worker.
I therefore thought I'd see if it's possible to automatically disable said device (or device driver) when I connect an external mouse, like a BlueTooth mouse or whatever, and then revert the effect whenever it would disconnect.
Is this a somewhat non-trivial task? If not, which programming language should I pursue my goal in? I've listed Java as a tag as it's my go-to language of choice.
Disclaimer: I wasn't 100 % percent certain whether to post this on stackoverflow or programmers, or even serverfault. I figured I'd try here as I'm after a programming solution.
You can do this via devcon - it's essentially a command line utility that allows you to control hardware (remove/disable/enable/rescan). The C source for this tool is in the WDK, so you could get it then wrap it in a DLL to use via JNA/I (or you could just make command line calls from Java to the devcon.exe itself).
How can I disable OS-level keyboard shortcuts (e.g. Alt-Tab, Ctrl-Alt-Left/Right, etc.) on a [Ubuntu] Linux machine? I'm developing a full-screen Java Swing app and don't want the user to be able to task switch away from the program arbitrarily. It's not enough to toggle the "always on top" flag; users mustn't be allowed to switch workspaces, migrate focus or any other such things. The machine must function normally before and after the application is executed. Google says that this will require JNI or JNA but I'm looking for a bit more hand-holding.
There's no point in trying to do this in your application because any of these changes are going to need to be handled by X11 and/or the window manager since those are what respond to the commands. Assuming that you have control of the platform, choose a window manager which supports a kiosk mode. Then use the window manager's settings to start your application and enter kiosk mode.
Options for window managers which can do this include KDE or twm-kiosk.
(And if you don't have control of the platform, you're not likely to be able to have your application intercept things like ctrl-alt-backspace anyway.)
Edit:
In response to a scaled-down version of the question in which he's willing to let things like ctl-alt-backspace go and just wants most of the keys including alt-tab or other similar application switching key combinations, the following should work:
You should be able to do this using XLib's XGrabKeyboard method through JNI. This Java/XLib JNI keypress capture tutorial should be a good starting point. However, it uses XGrabKey which just passively listens for keys and does not prevent other applications from receiving them. You'll instead want to use XGrabKeyboard which actively snags all of the normal keyboard events (which, if the premise of this StackOverflow question is correct, includes the task switching keys).
Note that as a side-effect, key capture in Swing will also probably stop working because your Swing windows are going to be separate from the window you create in C. As such, you will probably have to use your JNI interface to get key presses to your program when needed. (Although I would definitely advise testing it first before writing the code.) You might be able to avoid this if you can get the window using Java AWT Native Interface to get the window ID. (Note that Swing is built on top of AWT, so this will work for Swing.) However, I'm not sure how to do this. It looks like you might be able to navigate the window tree by getting the root window from the Display and going from there to find your Window, but it's all kind of weird. It would be nice if the AWT NI just told you the window ID, but it doesn't look like it does that.
As this warning Reminder: XGrabKeyboard is not a security interface notes, this doesn't make it impossible for other programs to see the keys, but it seems likely that window managers will not be using XQueryKeyMap so it is likely to prevent task switching.