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.
Related
I developed a somewhat simple GUI in Java Swing, and for some reason I am seeing some spooky behaviour.
On one computer when the swing window is open on the laptop's own screen it looks normal, but when moved to the second screen it turns completely black, even when it is partly in one and partly in the other it is shown correctly on the laptop screen and black on the other.
I can not reproduce it on my own computer (even though I have three screens), so I wanted to ask if anyone else has had similar experiences.
One idea to a reason could be that the laptop and second screen has different color depths, and that is messing with it.
Any pointers as to why it happens and a solution would be most welcome.
I just witnessed the same behavior when trying to use Freemind on my secondary monitor. A quick Google seems to indicate that it's a Java bug.
More context :
JRE 1.8.0_121 (latest version)
Windows 10
the bug happens whether the second monitor is configured on the left or on the right of the primary monitor (so probably not an issue with negative screen coordinates)
the really spooky part is that FreeMind displays properly if I drag the window to the secondary monitor slowly enough so maybe there's an issue linked to refresh rates.
the issue may be linked to the zoom factor set up on each monitor (125% on my primary vs 100% on my secondary) as the window visibly resizes when I move it from one monitor to the other
Hope this helps.
NB: this should be a comment rather than an answer, but I don't have enough reputation points yet ;)
Edit April 2018 :
For those still stumbling on this: on the same PC, the bug has disappeared after some software updates. I'm now running JRE 1.8.0_144, Windows 10 Pro 1709 (build 16299.371). My best bet is that a Windows update fixed the issue; window resizing and zoom factors now work much better than a year ago for legacy/Java applications (JMeter, Gimp).
I met this issue with apache-jmeter-r1839892 (nightly build of jmeter 5), my environment information is like below:
JRE 1.8.0_101 32bit
windows 10, Version 1607 build 14393.1944.
Inter(R) HD Graphics 530
NVIDIA Quadro M1000M
After I upgrade to JDK 10.0.2 64bit, then it works.
The root cause for me is most likely mentioned:
http://www.drastic.tv/support-59/supporttipstechnical/66-javaondualmonitors
Below solution mentioned in above link works as well with JRE 1.8.0_101 32bit
Start->Control Panel->System
Click the Advanced Tab
Click the Environment Variables button
Click the New button
For Variable name: _JAVA_OPTIONS
For Variable value: -Dsun.java2d.d3d=false
I also found another workaround: open jmeter, set the 2nd monitor as the main display in Windows and then switch back the 1st monitor as the main display.
I also tried to upgrade to JDK 1.8.0_181 64bit, the issue persists.
There're three, possibly related issues, that we've experienced in JxBrowser -
1.) Typing inside an input box inside the flash window doesn't work in JavaFx but works fine in Swing. This seems to be mostly a focus related issue.
2.) If a flash input box is clicked, then there's a noticeable lag after each keystroke. This ruins the user experience.
3.) Copy paste inside flash doesn't work when caps-lock key is on.
Are there any work-around for the above mentioned issues ? We've tried 6.1, 6.5, 6.6 and 6.7 versions and all have the same issues.
Thanks
I recommend that you try to enable heavyweight rendering mode in JxBrowser. Maybe you use lightweight rendering mode that runs Flash off-screen, so it might behave differently causing this slowness.
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.
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?