1

I have a simple UI, no animations. Enabling G-SYNC for windowed applications and having focus in the window causes the mouse to be choppy when moving over the whole monitor. FRAPS shows that the window has ~2 fps.

A workaround is to cause repainting. Selecting text or resizing the window increases fps up to the monitor refresh rate (120 fps), which makes the movement look normal.

Using AnimationTimer produces 120fps, but also consumes CPU:

private boolean focus = false;

public void setStageAndSetupListeners(Stage stage) {
    stage.focusedProperty().addListener((ov, onHidden, onShown) -> focus = ov.getValue());

    AnimationTimer timer = new AnimationTimer() {
        @Override
        public void handle(long now) {
            if (focus) {
                label.setVisible(false);
                label.setVisible(true);
            }
        }
    };
    timer.start();
}

I would like the JavaFX app to behave like any other desktop application - without consuming unnecessary CPU and not being choppy, or at least detect g-sync so that I can enable the workaround.

Win 10, GTX 980Ti, JDK 18

EDIT:

Workaround 2 (bad - font is mangled - screenshot):

-Dprism.order=sw https://stackoverflow.com/a/18773007/685796

Workaround 3 (good - it seems fine):

-Dprism.forceUploadingPainter=true http://werner.yellowcouch.org/log/javafx-8-command-line-options/

But it is only intended for testing and not recommended for production source

Reported here: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8289505

Meo
  • 12,020
  • 7
  • 45
  • 52
  • 2
    If you think it is a bug with JavaFX, then follow the [JavaFX bug reporting procedures](https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report). The OpenJDK site is currently down for maintenance, so I guess try later. – jewelsea Jun 16 '22 at 18:20
  • 2
    You may be interested in: [How fast is the JavaFX animation timer – let’s test it!](https://edencoding.com/animation-timer-speed/). It isn't an answer to your question but may provide you with some insight that may help understand how frame rate works with JavaFX. – jewelsea Jun 16 '22 at 18:36
  • 2
    You could also try asking your question on the [openjfx-dev mailing list](https://mail.openjdk.org/mailman/listinfo/openjfx-dev). – jewelsea Jun 16 '22 at 18:37
  • Your implementation of `handle()` runs on the JavaFX application thread, so this note in [`Platform.runLater()`](https://openjfx.io/javadoc/17/javafx.graphics/javafx/application/Platform.html#runLater(java.lang.Runnable)) may apply: "applications should avoid flooding JavaFX with too many pending `Runnables`." – trashgod Jun 16 '22 at 22:02
  • 1
    I found more workarounds... -Dprism.forceUploadingPainter=true seems to fix it – Meo Jun 17 '22 at 06:34
  • For context: The [`prism.forceUploadingPainter`](https://github.com/openjdk/jfx/blob/fdc88341f1df8fb9c99356ada54b25124b77ea6e/modules/javafx.graphics/src/main/java/com/sun/prism/impl/PrismSettings.java#L348) setting documentation comment is: "Force uploading painter (e.g., to avoid Linux live-resize jittering)". – jewelsea Jun 17 '22 at 18:30
  • The switch decides whether the [UploadingPainter](https://github.com/openjdk/jfx/blob/fdc88341f1df8fb9c99356ada54b25124b77ea6e/modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/UploadingPainter.java) or [PresentingPainter](https://github.com/openjdk/jfx/blob/fdc88341f1df8fb9c99356ada54b25124b77ea6e/modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/PresentingPainter.java) is used. The UploadingPainter renders to an offscreen buffer, whereas the PresentingPainter renders directly to the screen. – jewelsea Jun 17 '22 at 18:31
  • Perhaps best to post the workarounds as a [self-answer](https://stackoverflow.com/help/self-answer). – jewelsea Jun 17 '22 at 18:38
  • https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8289505 – Meo Jun 30 '22 at 08:26

0 Answers0