Develop Reference

JavaFX sporadic rendering issue - disappearing buttons / controls

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).

LWJGL java.awt.HeadlessException thrown when making a JFrame

Hi I'm working on a group project and the code works on my teammate's PCs but I keep hitting MacOS specific errors. And this time I seem to be stuck (no easily Googleable answer).
In a previous post I discovered I need "-Djava.awt.headless=true" as VM setting to properly run my simulation. Now when I try to spawn in some JFrame they are all met with a lovely "java.awt.HeadlessException" Exception because of that VM flag.
Trying to achieve
I want to be able to spawn those JFrames on my MacBook also.
The problem
I need -Djava.awt.headless to be both true and false at the same time for my program to run properly on Mac. Which if I understand my problem correcly, means I have a big problem on my hands.
EDIT: running it in a VM on my Macbook allowed me to run the project properly. This is far from an ideal fix. I'm still searching for a solution to this obscure problem.
What I tried
not running with the VM option: the problem described in previous post occurs. Thus this is not a viable option
running with the VM option: this throws a -Djava.awt.headless when creating a JFrame.

The best way to fix this may be by going back and solving your original problem a different way.
You must make sure that you are not initializing your BufferedImage in the main thread (GLFW thread), it MUST be done separately. It is hard to tell from your original question, but that looks like part of the cause there. Start a new thread to do the image processing instead.
See my solution and recommendation at the bottom of this answer for a quick summary, and also see here for someone else that had the same issue: Java Creating Instance of BufferedImage Freezes Program
A quick note on why your code works on Windows and not Mac: that is because both OS often run different implementations of openGL, and typically Mac can lag behind and miss out on a bunch of updates/changes that may solve problems like this one so that it doesn’t freeze when initializing a BufferedImage on the openGL thread.
If the above didn’t work then lets first look at what headless mode is. (Emphasis mine):
See link at bottom for full article and more info.
Headless mode is a system configuration in which the display device,
keyboard, or mouse is lacking. Sounds unexpected, but actually you can
perform different operations in this mode, even with graphic data.
Where it is applicable? Let's say that your application repeatedly generates a certain image, for example, a graphical authorization code
that must be changed every time a user logs in to the system. When
creating an image, your application needs neither the display nor the
keyboard. Let's assume now that you have a mainframe or dedicated
server on your project that has no display device, keyboard, or mouse.
The ideal decision is to use this environment's substantial computing
power for the visual as well as the nonvisual features. An image
that was generated in the headless mode system then can be passed to
the headful system for further rendering.
So when should headless mode be used:
On a machine that has no display device, keyboard, or mouse.
That is not you is it? However if that is you (LWJGL?), then lets look at how you can work with headless mode:
An image that was generated in the headless mode system then can be
passed to the headful system for further rendering.
This means that you should have a special piece of headless code that does your headless image stuff, but then passes the image back to a normal JFrame with a head.
So why does it fail for you:
Many components are affected if a display device, keyboard, or mouse
is not supported. An appropriate class constructor throws a
HeadlessException
Button
Checkbox
Choice
Dialog
FileDialog
Frame
Label
List
Menu
MenuBar
MenuItem
PopupMenu
Scrollbar
ScrollPane
TextArea
TextField
Window
Solution to the problem:
some classes, such as Canvas or Panel, can be executed in headless mode.
Perfect, so we just need to be careful what is used in headless mode. You asked how you can both use and not use headless mode, well rather than globally setting headless mode with VM option -Djava.awt.headless you can do it programmatically within your code using System.setProperty("java.awt.headless", "true"); where needed. A JFrame should be normal (not Headless), but you can spawn a JPanel as headless without issue.
I recommend:
You create a normal headed main thread with no VM option that spawns JFrames, and then use that main thread to spawn a new child thread and set your LWJGL bits in that thread to be headless, and that way you can run your LWJGL code without issue, and at the same time you can still have JFrames from your main thread. Remember to make sure that the Buffered image is not done in the main LWJGL/OpenGL thread.
Headless info source:
http://www.oracle.com/technetwork/articles/javase/headless-136834.html

Screen in Android Virtual Device is too large

I've this problem that my screen in Android Virtual Device is out of view. I have tried reducing the scaling by -0.75, as stated by others, but it doesn't seem to help.
Notice how the button to unlock the screen is out of view. How do I solve this issue?

You could use the context menu of windows. Right-click with your mouse on the AVD and chose move. Then your AVD should not be "locked" anymore (and maybe you can adjust the size then too).

JavaFX 8 screen rendering freezes when running with hw acceleration enabled

One of our JavaFX 8 freezes quite frequently when running on Microsoft Surface 3, every now and then when running on a different tablet running Windows 8 and once in a blue moon when running on a normal desktop.
If we run it with prism.order=sw, it doesn't freeze but the performance on tablets is a little bit too slow to be usable.
When it the screen freezes, one can still click on the screen and all events and the JavaFX thread appear to be working as usual but it just seems that the prism / quantum rendering or whatever it is that it actually converts the scenegraph to pixels crashed.
I've reported a bug in the old JIRA and new JBS and apparently we need to produce a reproducible test case which we don't have time to prepare.
Any ideas as to why this can be happening? Anyone has had this happening as well? Any hints as to how to get to the root of the problem?

Swing app freezes in dual screen windows 7 environment when moving app to top right hand corner of second monitor

I built this Swing app to help my girlfriend get a particular job done faster. On my dual monitor windows system, the app and the Operating System freeze when moving the app to the extreme right hand side of the second monitor. Windows recovers, but the app does not. Has anyone experienced this sort of issue and know how to solve it? Below is the github link to the source code.
I tried to also provide a screenshot of the frozen app and the OS but it is difficult to take one when the OS freezes.
The app works fine on her Mac.
https://github.com/johndeverall/BehaviourCoder