We've faced a problem with Swing under Windows 10. Sometimes, when Windows 10 goes unlocked, our Swing application looks damaged. This problem comes sporadically for Windows 10 only. For Windows 7 we cannot reproduce this behavior. After some days of researches I've found the problem: Swing for some reasons calls the method SwingUtilities.updateComponentTreeUI, which reset some of my UI hacks, that was required to provide better look for my components. My problems look like the problem described in this topic, but I cannot use answer offered in the topic. The only one idea I have to fix this problem, is overriding of method updateUI in my "hacked" components to prevent reset of UI (so the UI can only be refreshed, when no UI was set before).
Have probably somebody better idea to solve this problem?
Related
In this page the CheerpJ conversion of the applet in this page (with identical byte-code) does not seem to recognize mouse dragging past the applet frame boundary. It would be nice if that were possible.
Is this just a problem with my client-side setup (Linux Debian 9.2), or do others see the same behvior?
What is very strange, is that the original behavior is converted correctly on the not-supported-by-CheerpJ iphone browsers (I have checked safari and firefox there). Could investigation of this fact help CheerpJ developers understand how to make the MouseMotionListener interface recognize mouse dragging anywhere on the screen, not just within the applet frame?
Maybe this is impossible, but I thought it was worth asking.
Edit: Changed title to be less negative about CheerpJ (which overall I find almost too cool to be true!) and more reflective of actual the question.
The mouseDragged method is correctly implemented to the best of our understanding. The Java event is derived from the mousemove JavaScript event which is not delivered when the mouse is outside of the applet surface. With the legacy plugin applets are displayed on native windows which have different behavior.
It could be possible that using different JavaScript events, like mousedrag would make CheerpJ behavior more similar to native, but reworking this without causing regressions would require significant work and it is not currently a priority for us. Especially considering that our customers normally have full screen Swing applets which cannot exhibit the problem
On mobile devices the touchmove event is used, which is probably what causes the difference you see.
If you want to report a bug you can do it here: https://github.com/leaningtech/cheerpj-meta/issues
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).
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've just started making my first GUI application in Java and I decided to use the NetBeans IDE to do it. I think its working fine so far, except for one problem; it seems to be slow updating the content of a window.
Even in very simple windows with few controls I find that when - for example - closing or resizing a window, I get the normal window border working properly but the inside is completely see through for a second.
It's not the biggest deal in the world, I just find it mildly annoying.
EDIT: I've tried the HelloWorldSwing from the official Java tutorial but I have the same issue, only now, when resizing, instead of being transparent, the new area of the window is black until the contents updates.
You should ensure that all of your GUI updates are performed in the Event Dispatch Thread, and that any other long running tasks are performed in worker threads. If you have long running tasks running in the EDT, your GUI will feel sluggish. Take a look at this tutorial for concepts on Swing Threading.
In the absence of any technical problems with your app, this could simply be JVM warmup effects. Do updates speed up if you resize the window a few times?
This could be a Java2D hardware accelleration issue. Is your 3D graphics card driver fully updated?
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.