I have a Java/JavaFX application deployed as a native install for Windows and Mac. The bundled runtime is currently 8.121. You can find the installers and the Java code here: George download
I have been using this application in the classroom weekly (with 20 children) for the last 15 months, and right from the start I have seen the following problem:
From time to time, buttons disappear. That is to say, they are simply rendered as a white rectangle, making them effectively almost invisible. Both the background and label/text disappear.
This mainly happens on mouse-over, but then does not correct itself.
The buttons are still there, and clickable.
It only happens sporadically, but it seems to recur on certain machines more than others. Windows 10 now, but used to the same happened on tiny Windows 7 machines previously.
I am not able to reproduce it myself and have never seen it on a Mac, I think.
It now also happens sometimes with other widgets/controls, and even before any user interaction.
Is there some known issue around this?
Has anyone else described something similar?
Might it have something to do with certain minor operating system adjustments?
Any thoughts or ideas would be much appreciated.
Update (2018-11-06)
Just started testing my application in Java 8 in VirtualBox with Windows 10, and I now get the rendering error myself. Hurra!
Looking into the -Dprism.xxx options, I found this article:
http://werner.yellowcouch.org/log/javafx-8-command-line-options/
Testing with -Dprism.threadcheck=true, I get a lot of
"ERROR: PrismPen / FX threads co-running: DIRTY: false" with stack traces.
Setting -Dprism.dirtopts=falsedoes not solve it for me, though.
But running with -Dprism.order=sw does. But this is not a good solution for an application that may do some demanding rendering (Turtle Geometry).
Will keep digging.
I've been having the same issue, I tried updating to Java 10 but the issue remained. I then edited the properties on java.exe and on the 'Compatibility' tab I set 'Override high DPI scaling behavior' to 'System (enhanced)' and the problem seems to have gone away (or at least it hasn't happened again yet).
I observed the same thing: Visually disappearing (but still functional) buttons and other controls (except labels) especially in areas outside the original size of the window after I have resized it manually)
In my case -Dprism.dirtopts=false reduced the problem but also didn't solve it (and was not really a satisfying solution anyway).
Additionally I observed that some TextField controls also showed rendering glitches (looked like the same text was rendered twice with a little offset). That finally put me on the right track:
It turned out to be just a missing Platform.runLater(...) around some calls to TextField.setText(...) (from another thread) for exactly these TextField controls, which was causing this (even for e.g. a Button which is at a totally different place - also in the widget hierarchy).
I know, this is probably not the answer in all cases, but hopefully it helps at least some others facing the same problem (took me a full day to find out).
Related
I have a old application running a Swing client. I upgraded from Java 7 to 8 a long time ago. The upgrade went fine. Ever since I have wanted to upgrade to Java 9, then 11 and now 13. However this is where I meet problems.
The UI looks fine and as intended with Java 8, but any newer Java version will somehow change the font sizes and maybe components for some reason. I do not have any pictures to show because the application is maintained on a network without internet access because of security reasons. The client looks like most thing is multiplied with a factor of 2.0 or something. It appears as zoomed or maybe something you would create with universal design in mind. Even the splash screen is doubled in size for some reason and that is an image. There are some exeptions. The title text in the windows is the same. Also text on buttons and lables seems to be equal. Icons, images (splash) and text inside textfields/editors is much larger.
I have tried to find a solution for a long time but have not found anything. I am hoping someone else have experienced this problem or at least know what the problem could be.
Holgers comment about OS scaling was the issue. I have a 4K screen with 150% scaling set in the OS. Putting it back to 100% made the Java Swing Client look the same as when running Java 8.
To override add -Dsun.java2d.uiScale=1
Se also https://superuser.com/questions/988379/how-do-i-run-java-apps-upscaled-on-a-high-dpi-display
Ok, so this is a really, REALLY weird issue that we're having with the application at my company. I'm going to try and describe this as best I can.
First, this is a legacy application with a Swing UI.
Second, the issue only occurs when it is compiled & run using Java 8. With Java 7 and below, this does not occur.
So, the issue: When a dialog is displayed (modal or non-modal, doesn't matter), the UI becomes unresponsive to mouse clicks. What's truly crazy, though, is the UI is NOT frozen. Hovering the mouse over something produces the hover highlight as normal. Keyboard commands are received perfectly. Mouse clicks, however, do not work.
This also only occurs on OSX. Windows and Linux don't have this problem. I'm running this on OSX El Capitan.
As far as code samples, it's affecting all dialogs across the application. JOptionPanes & JDialogs, doesn't seem to matter. Here's a simple JOptionPane declaration:
int n = JOptionPane.showOptionDialog(mcContext.getMapperView(), "xPath of dropping target can't be evaluated" +
"\nPlease, select xPath for dropped node",
"xPath calculation for dropped node",
JOptionPane.YES_NO_CANCEL_OPTION, JOptionPane.QUESTION_MESSAGE, null, options, options[0]);
This code IS being called on the EventThread, so I don't believe it's a threading issue.
I'm totally stumped as to the cause of this. So far we've ignored it by compiling and running it in Java 7, but at some point as versions progress we will need to deal with this issue more directly.
Anyone have any ideas?
Edit: Thanks for the SSCCE Idea. Now I'm more confused than ever. When I put together a quick frame/dialog demonstration, it worked perfectly. No issues. So I don't know what it is in the application that could be causing this. Any good places to start looking?
Edit 2: Wrapped one of the declarations in SwingUtilities.invokeLater, and it worked. Ok... now what could the culprit be? It's still got to be something that Java 8 is compiling different than Java 7.
Edit 3: More weird behavior. I moved my IDE into a separate "desktop" than the application it was running, and when the buggy dialog is displayed, i cant switch to that desktop. I can switch to any app on the current desktop, but not to another desktop.
Edit 4: The dialogs in question are being triggered by drag and drop actions. Not sure if that helps or not, but I do see that there is a thread in the background in the thread dump using the sun.lwawt.macosx.CDragSourceContextPeer class.
Alright, it took a while, but I think I found it. I found an OpenJDK post that seemed to very clearly describe this issue.
https://bugs.openjdk.java.net/browse/JDK-8139393
Somehow, Drag N Drop in Swing on OSX in java 8 isn't releasing its hold on the MouseEvent or Listener, so when a modal dialog is displayed the mouse isn't able to get new events through to it. Which is a crazy stupid bug, but it's there.
The solution was wrapping my code in SwingUtilities.invokeLater(...). By having the code that displays the dialogs executed asynchronously from the drag and drop code, the drag and drop operation is able to complete and release its hold on the mouse connectivity (for lack of a better description). And viola! Problem solved.
Thanks to everyone who tried to help. Hope this post helps out anyone else dealing with this issue.
I have a Sikuli script written in java to click the windows start button and then click "All Programs" as appear. The script works absolutely fine on my computer but when I transfer the same script to another computer, it doesn't work.
Code:
Screen screen = new Screen();
screen.type(Key.WIN);
screen.click(IMAGE_DIR + "program.PNG");
I used concepts like Wait, Pattern and similar but not able to solve this issue. Not sure if this is a limitation of sikuli.
Like was already mentioned in the comments, differences in screens resolutions will definitely ruin your existing scripts as Sikuli is super sensitive to them. In such case, the only solution is to recapture the patterns and use a different set of them on each machine.
However, if you have such issue but screens resolutions seem to be identical, there are few more things that should be checked.
Clear Type, which is Microsoft's implementation of subpixel rendering that is supposed to improve the fonts visual appearance. If you have this feature switch on on one machine and switched off on another, that might be an issue.
Smooth Edges of screen fonts setting that can be found in the "Visual Effects" settings window in "Performance Options". It does exactly what it says, smooths windows fonts to improve the looks. As in the case of ClearType, this feature should be switched off or on on both machines you run your scripts on. The general recommendation to have the always off to avoid this kind of issues.
For those still using Sikuli and experiencing inconsistency when running across different machines, it's helpful to debug on the boxes that are showing the issue.
Some things like issues around various AppData temp files not being managed correctly can show up in some PCs but not others. It's a pain to install your IDE into different places but it sometimes is the only way to really see what's going wrong - and be able to fix it.
I have a web application (struts 1.3, Weblogic 10.3.0, Toplink, Oracle) that has a Java applet which isn’t working in the browser (IE7/8) when the Next-Generation Plug-in setting is enabled in the Java control panel but works fine when it’s disabled. The trouble is that this setting is set to disappear in an upcoming Java release meaning that my users would have to keep using Java 1.6_xx on their workstations as they are currently. I have little influence over which version they use because they are all governed by their local IT departments across the country. So, either I have to find a simple fix to allow the Next-Generation setting to work, or we have to look at replacing/rewriting the applet with something else (but would be a last resort due to funding constraints), most likely something AJAX-friendly so as to avoid the need for a plugin. This application is quite old, written around 2001 before AJAX was really around.
The main window has a left, right, and top frame (JSP’s), as well as a center frame which is where the applet is. The applet has a main content area in the middle and a lower panel at the bottom which has some buttons. The buttons tell the content area (which is basically a treegrid) what to do (Save, Copy, change status, etc ). When I press one of the buttons the entire window (surrounding frames plus the applet itself) repeat inside the area where the applet is. It’s like a kaleidoscope or like a repeating fractal pattern kind of thing, or like when you take a picture of yourself in the mirror and you see the room repeated over and over in the mirror. In this case it repeats for each button press and the repeated set gets smaller each time. Weird!!
So, based on my research, the Java Next-Generation plugin works differently by allowing more than one process or thread whereas the classic plugin only uses a single thread. So my suspicion is that a new process is being spawned for each button press. I tried using the “separate_jvm” applet parameter but it made no difference whether it was set to true or false. I don’t see any other applet parameters which seem to be relevant.
Another idea I had is that maybe it’s something to do with the JSP frameset, maybe something like “target=_top” needs to be added somewhere…but I’m not sure how this relates to applet threads if at all.
Anyone have any suggestions, ideas or experiences that might help?
you can use velocity to handle these type of problem and it will also help you for future enhancement also.
The problem is not related to version of IE but rather to version of Java. Below excerpt from letter of certificate provider (they took it from some forum, so direct link to source cannot be provided):
For JDK version higher than 1.6.0 and below 1.6_15, you can just
clear all kinds of cache in web browser, java console and java control
panel. Then it should works fine!
For JDK version between 1.6_15 and 1.6_30, you should disable the "next-generation java" option in java control panel.
For JDK version higher than 1.6_30, you should turn on "next-generation java" option in java control panel.
We have a problem in our swing based application since we've upgraded our java version from 6u5 to 6u18 (The application runs over WinXP).
Our application contains a Canvas object which resides in a JFrame. The application draws things on the canvas.
Every time we drag a lightweight swing object (popup or another frame) over the canvas, it has a refresh problem.
It blinks - becomes black. The problem only resolves after we move the swing component away from the canvas and click on it again.
We think this problem is related to the fact the the canvas is a heavyweight object.
And we know there were changes done in the new versions of java on the mixing of heavyweight and lightweight objects issue.
Some more details:
1) Our problem reproduces in java 6u14 and 6u16.
2) Everything works fine in java 6u5.
Another strange thing:
We have 2 types of stations running our application.
The first type has a ATI FireGL7100 PCI-E graphics card. The second type has a Matrox G450 PCI graphic card.
The problem does not reproduce on the Matrox based station in any java version.
One more thing:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6829858 - looks similar to our problem.
Is our problem familiar?
Do you have any suggestions (workarounds, ideas how the difference in graphics cards is connected to this problem)
Hope I was clear enough,
Yoav
The article Mixing heavy and light components describes how support for this changed in JDK 6 update 12. The two video cards may handle Z-order differently. Any chance your code has a workaround that's no longer needed?
We had problems w/ HW/LW mixing from 6u14+ (the fixes that breaks everything is in 14). Our problem was in a thirdy part library (JIDE) and they ended up fixing the problem on their end.
My suggestion is avoid HW where ever you can. You can get very decent performance out of LW if done correclty. What are you drawing that needs to be HW?
I don't know if this is relevant to anyone else, but we've found a workaround/fix for our problem.
We've set the system properties sun.awt.noerasebackground and sun.java2d.noddraw both to true. That eliminated our issue.
The only problem is that I'm not sure what other problems might rise from setting those system properties.