JavaFX stage *sometimes* appears blank on Win10

My class extends a JavaFX Stage. In a development environment it never fails to load and process, but my users regularly report that sometimes it doesn't properly show which looks like this on Windows 10.

The class itself is a fairly standard affair, I trigger it with Platform.runLater() and the thread processes as expected. Every log output is written out and it is possible to interact with the screen as programmed, or close it, which does not trigger any error or exception.

The stage constructor is pretty basic:

  log.debug("Constructing the screen.");

  setTitle("Screen");
  setAlwaysOnTop(true);
  initStyle(StageStyle.UNDECORATED);

  try {
        FXMLLoader fxmlLoader = new FXMLLoader();
        fxmlLoader.setLocation(getClass().getResource("....fxml"));

        Pane panel = fxmlLoader.load();
        controller = fxmlLoader.getController();
        controller.postInit(currentIdle); // some elements processed

        Scene scene = new Scene(panel);
        setScene(scene);

        scene.setOnKeyPressed(controller::handleKeyEvent);
        setOnHiding((WindowEvent e) -> processor::leaveScreen);
        log.debug("Showing the screen.");
        show();
        log.debug("Screen shown.");

        requestFocus();
        log.debug("Finished constructing the screen.");

} catch (IOException e) {
    // ...doesn't go here
}

From the logs everything seems to work as intended, including the controls, keyboard shortcuts and the leaveScreen() hook, and there are no exceptions thrown, except that the user sometimes cannot see the content and controls on the screen.

What am I looking at? Is this a problem with my code, or a JavaFX bug? A problem with graphics on the user laptop? Can you think of a way to prevent or at least detect this state and force a refresh somehow?

Alternatively, under what circumstances is it possible that a JavaFX stage passes its show() method without an error, but does not actually show its contents?

Environments affected: All combinations of latest JDK 14 GA, Corretto 11, (custom jlink-created image) and JavaFX 11.0.2 or 14.0.1 - it does not make a difference. It also happens regardless of whether the application is installed with a jlinked JRE using jpackage or Advanced Installer.

Warm thanks, guys, for your honorable attempts to help. It is now a bit cold at nine months later, but I believe that it deserves a close in case anyone stumbles upon the problem later. My conclusions:

1. The problem is not caused by my application, and
2. that I have found a workaround.

We gradually managed to confidently isolate the problem to hardware, i.e. we noticed it would happen more frequently if plugging/unplugging display peripherals and docking stations was involved. It was also sometimes triggered by sleeping / running out of battery oddly.

This led us to believe that the problem was somewhere between Prism's hardware acceleration and the graphic cards. In the end we managed to avoid this kind of rendering freeze by changing the application's GraphicsPipeline from com.sun.prism.d3d.D3DPipeline to com.sun.prism.sw.SWPipeline. For us this is not a problem, because the application doesn't render complex 3D graphics, and after switching to software rendering the problem disappeared.

This can be achieved by setting -Dprism.order=sw to the JVM parameters at startup. You can confirm the pipeline in use by logging your com.sun.prism.GraphicsPipeline.getPipeline().getClass().getName().