Np, all you need to do is this:
```java
[code here]
```
I’ll try it out later today, I’m at least curious whether I’ll see similar issues.
1 Like
Thanks a lot!
Looking forward to your findings
I tried it on a 1280x720 video. The good news is, I didn’t notice any kind of lag or FPS choppiness issues. The bad news is I couldn’t reproduce the issue. lol
This was on Linux though, with a GTX 1070 and a pretty decent i7. So probably a pretty different setup. I was getting about 9000 FPS uncapped, consistent. When scaling to 1920x1080 from (approximately) the actual size, it dropped to about 5000 and stayed there.
Capped with:
settings.setFrameRate(60);
settings.setVSync(true);
JME FPS drops to a consistent 40. I guess that’s related to the the synchronization with JME’s thread.
Edit:
With vsync you don’t need the setFrameRate(60), by the way. But also… if I ONLY do the setVSync - I get a solid 60 FPS.
1 Like
Well that’s definitely good to here!!!
Yeah my PC isn’t equal to yours haha
Is there a way to private-message here? I don’t want to spam non-related things in here.
I am currently at refactoring, just to be sure would you help me test when I am finished with that?
JME FPS drops to a consistent 40. I guess that’s related to the synchronization with JME’s thread.
I noticed that too.
With vsync you don’t need the setFrameRate(60), by the way. But also… if I ONLY do the setVSync - I get a solid 60 FPS.
I know, I commented out “settings.setFrameRate(60)” and some other parts, but when pasting the code in here it complained I used too many links? e.g. //settings.setFrameRate60 
Click your avatar at the top right and click the envelope icon.
Don’t worry about spamming the thread, if it helps others then it’s not spam, it’s constructive 
2 Likes
Sure, if you think it’s helpful I can run some other tests later. If you use a code block like the example I put above, it won’t complain about “links”.
Convenient (Gradle) version of that media player test for anyone who wants to try it locally to see how it performs… Drop an mp4 into project root, update filename in code & Gradle.build as needed, run.
I tested in Linux, so of course it worked perfectly. 
Tests on inferior platforms advised.
1 Like
I think I’ve fixed this. I’ll do a little more in-house testing but I’m pretty sure it’s solved.
This does work, but all it’s really doing is turning off the JVM’s “module aware mode” (at least that’s what the authors of the book on modularity I’m reading said to describe it).
run {
doFirst {
jvmArgs = [
]
}
}
But yeah, I’ll help test whatever solution you’ve come up with.
I’ve pushed the changes to master. It appears to work fine for me. I’d be grateful if you wouldn’t mind seeing if it works.
This was the commit.
https://github.com/jayfella/jme-jfx-11/commit/fc14b9f2296b367206ed925c751b063c68218629
Oh that’s much better. Yeah that should work, I’ll give it a test run later.
Well, it did fix that problem. But it looks like it’s going to be a little harder for a working modular solution. And fixing the rest may not be so easy. Hopefully this isn’t too confusing:
Looking at the code, there’s quite a few more references to com.sun packages. All of those packages are off limits when the JVM is enforcing modular architecture rules (and they did it intentionally).
JavaFxPicture.java
import com.sun.javafx.embed.EmbeddedStageInterface; [position 6:1]
JmeFxContainerImpl.java
import com.sun.glass.ui.Pixels; [position 25:1]
import com.sun.javafx.application.PlatformImpl; [position 26:1]
import com.sun.javafx.cursor.CursorFrame; [position 27:1]
import com.sun.javafx.embed.AbstractEvents; [position 28:1]
import com.sun.javafx.embed.EmbeddedSceneInterface; [position 29:1]
import com.sun.javafx.embed.EmbeddedStageInterface; [position 30:1]
import com.sun.javafx.embed.HostInterface; [position 31:1]
import com.sun.javafx.stage.EmbeddedWindow; [position 32:1]
JmeFxContainerInternal.java
import com.sun.javafx.cursor.CursorFrame; [position 6:1]
import com.sun.javafx.embed.EmbeddedSceneInterface; [position 7:1]
import com.sun.javafx.embed.EmbeddedStageInterface; [position 8:1]
import com.sun.javafx.stage.EmbeddedWindow; [position 9:1]
JmeFxDnDHandler.java
import com.sun.javafx.embed.EmbeddedSceneDSInterface; [position 5:1]
import com.sun.javafx.embed.EmbeddedSceneDTInterface; [position 6:1]
import com.sun.javafx.embed.EmbeddedSceneInterface; [position 7:1]
import com.sun.javafx.embed.HostDragStartListener; [position 8:1]
JmeFxHostInterface.java
import com.sun.javafx.cursor.CursorFrame; [position 8:1]
import com.sun.javafx.embed.AbstractEvents; [position 9:1]
import com.sun.javafx.embed.EmbeddedSceneInterface; [position 10:1]
import com.sun.javafx.embed.EmbeddedStageInterface; [position 11:1]
import com.sun.javafx.embed.HostInterface; [position 12:1]
CursorDisplayProvider.java
import com.sun.javafx.cursor.CursorFrame; [position 3:1]
import com.sun.javafx.cursor.CursorType; [position 4:1]
ProtonCursorProvider.java
import com.sun.javafx.cursor.CursorFrame; [position 10:1]
import com.sun.javafx.cursor.CursorType; [position 11:1]
JmeFXInputListener.java
import com.sun.javafx.embed.AbstractEvents; [position 16:1]
import com.sun.javafx.embed.EmbeddedSceneInterface; [position 17:1]
So the new startup-time error that I get is this:
Uncaught exception thrown in Thread[main,5,main]
IllegalAccessError: superinterface check failed: class com.jayfella.jme.jfx.injme.JmeFxHostInterface (in unnamed module @0x77f9ed68) cannot access class com.sun.javafx.embed.HostInterface (in module javafx.graphics) because module javafx.graphics does not export com.sun.javafx.embed to unnamed module @0x77f9ed68
Honestly though, I’m not sure this is really worth fixing at this time. Is anyone here using Java modules yet? I doubt it.
Even if we converted the project into a module and add the necessary requires commands, those sun packages aren’t being exported by javafx.graphics. They’d still be inaccessible.
It’s way easier to just remove the OpenJFX Gradle plugin’s runtime JVM parameters that’s causing the JVM to start in module-aware mode.
If there’s interest I can continue helping go further down this modular path, but I’m thinking nobody really needs this now? I expect removing all sun references to be a long term project.
Or I could donate a working demo which uses Java 11 + JME + OpenJFX-Gradle plugin. I’m only using it because they split JFX out of the base JDK after Java 10 and I don’t want the hassle of the extra setup. I think it needs an update to allow skipping the module parameters at runtime.
And now the “discourse” forum nanny is telling me to stop spamming the thread… 
Edit: Still researching the topic, there might be a way to get access to packages locked down by default… but a little distracted by other issues atm. 
Any plans on upgrading to OpenJFX 12?
Actually I’ve already done the ground-work for it. If memory serves, it’s just a few lines of code. I could release a version for it if there’s enough want for it.
Edit: yeah it’s just this file. There are two areas remarked “java 12 implementation”. You can literally unremark the v12 and remark the v11 and that’s it.
Ok great! Is there any reason to stick to version 11 at this point? It seems the migration path to 12 would be completely transparent.
I thinks it’s more a LTS thing than anything else. I think the next LTS is java 17, so one version every 6 months. If you jump to 12 you effectively jump on a cycle train until the next LTS.
The only OpenJFX LTS I could find was being offered by Gluon for enterprise support. Otherwise, the free OpenJFX is only guranteed support for six months. I could be wrong though.
That may be, but if this is built against JDK 12 and the end-developer wanted to stick with JDK 11 for LTS… they’ve got an issue.
Then again there may not be a good reason to stick to an LTS version for a JME app anyway. I don’t think I’d care about sticking to 11.
Hi @jayfella . It seems that scroll events are detected only as MOUSE_MOVED when using jme-jfx. This prevent us from scrolling any Node.
Here is two tests with a scrollpane.
Without jme-jfx, using only javafx (Works):
import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.control.ScrollPane;
import javafx.stage.Stage;
public class ScrollWithoutJmeJfxTest extends Application {
public static void main(String[] args) {
launch();
}
@Override
public void start(Stage stage) {
ScrollPane scrollPane = new ScrollPane();
scrollPane.setPrefHeight(600);
scrollPane.setPrefHeight(600);
scrollPane.setPrefWidth(400);
Button button = new Button("My Button");
button.setPrefSize(400, 1300);
button.setOnScroll(System.err::println);
scrollPane.setContent(button);
scrollPane.setVbarPolicy(ScrollPane.ScrollBarPolicy.ALWAYS);
Scene scene = new Scene(scrollPane, 1000, 900);
stage.setScene(scene);
stage.show();
}
}
Using jme-jfx (Does not work):
import com.jayfella.jme.jfx.JavaFxUI;
import com.jme3.app.SimpleApplication;
import com.jme3.app.StatsAppState;
import com.jme3.system.AppSettings;
import javafx.event.EventType;
import javafx.scene.control.*;
public class ScrollWithJmeJfxTest extends SimpleApplication {
public static void main(String... args) {
ScrollWithJmeJfxTest main = new ScrollWithJmeJfxTest();
main.start();
}
ScrollWithJmeJfxTest() {
super(new StatsAppState());
setSettings(new AppSettings(true));
setShowSettings(false);
}
@Override
public void simpleInitApp() {
JavaFxUI.initialize(this);
ScrollPane scrollPane = new ScrollPane();
scrollPane.setPrefHeight(600);
scrollPane.setPrefWidth(400);
Button button = new Button("My Button");
button.setPrefSize(400, 1300);
button.setOnScroll(System.err::println);
button.addEventHandler(EventType.ROOT, System.err::println);
scrollPane.setContent(button);
scrollPane.setVbarPolicy(ScrollPane.ScrollBarPolicy.ALWAYS);
JavaFxUI.getInstance().attachChild(scrollPane);
}
}
What could be the cause of that?
1 Like
You’ve posted the same code twice so far as I can see, but to be completely honest I’m not 100% on why. It may have to do with JME capturing inputs beforehand. I’m not certain. I’ll have to look in to it.