Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LINUX Intel HD graphics 620 java.lang.RuntimeException in efxclipse-drift-samples #41

Open
Kepler-Br opened this issue Jan 25, 2021 · 8 comments
Assignees

Comments

@Kepler-Br
Copy link

Kepler-Br commented Jan 25, 2021

I have Intel HD Graphics 620 which is Intel Core i5-8250U on my linux ubuntu 20.04 notebook.
I was trying to run a demo from https://github.com/BestSolution-at/efxclipse-drift-samples. It starts, but when I push "start" it throws error at me which says:

java.lang.RuntimeException
        at org.eclipse.fx.drift.internal.frontend.FxImageFactory.createFxImage(FxImageFactory.java:37)
        at org.eclipse.fx.drift.internal.frontend.SimpleFrontSwapChain.<init>(SimpleFrontSwapChain.java:58)
        at org.eclipse.fx.drift.internal.frontend.FrontendImpl.doCreateSwapchain(FrontendImpl.java:99)
        at org.eclipse.fx.drift.internal.frontend.FrontendImpl.receiveCommand(FrontendImpl.java:137)
        at org.eclipse.fx.drift.internal.backend.BackendImpl.sendCommand(BackendImpl.java:85)
        at org.eclipse.fx.drift.internal.backend.BackendImpl.createSwapchain(BackendImpl.java:45)
        at org.eclipse.fx.drift.internal.RendererImpl.createSwapchain(RendererImpl.java:88)
        at org.eclipse.fx.drift.samples.lwjgl.ObjDemo.loop(ObjDemo.java:438)
        at org.eclipse.fx.drift.samples.lwjgl.ObjDemo.run(ObjDemo.java:495)
        at java.base/java.lang.Thread.run(Thread.java:834)

But it starts perfectly on PC with Nvidia 1060 6gb which is also linux ubuntu 20.04.
Have no idea what to do. Error message is quite cryptic.
I have tried to change LWJGL version but nothing happens.

@tomsontom
Copy link
Contributor

But isn't there any message in the stacktrace?

@tomsontom
Copy link
Contributor

Ok looking at the code it looks like this happens if your graphic card does not support the es2 pipeline of JavaFX. @redrezo We should throw an IllegalStateException and provide the user some error message

@Kepler-Br
Copy link
Author

So, it's impossible to use DriftFX with Intel 620, right?

@tomsontom
Copy link
Contributor

Well 2 possibilities:

  • Force FX to use the OpenGL pipeline
  • since IIRC FX-13 has PixelBuffer support so we could provide a fallback but JavaFX would still run in Software-Rendering mode

The first we although have to find out is why has OpenGL disabled

@tomsontom
Copy link
Contributor

I reopen this one because we should definately fix the exception to tell the user what is going wrong

@tomsontom tomsontom reopened this Jan 26, 2021
@wgryglas
Copy link

wgryglas commented Mar 17, 2021

Hi,
I've got the same issue with Intel(R) Iris(R) Plus Graphics 640 on my Linux (Elementary OS, based on Ubuntu 18.04LTS)
Most likely this is caused by the wrong Prism pipeline recognition by the DriftFx code.

The JavaFX prints the following stats in my case:

Prism pipeline init order: es2 sw
Using Double Precision Marlin Rasterizer
Using dirty region optimizations
Not using texture mask for primitives
Not forcing power of 2 sizes for textures
Using hardware CLAMP_TO_ZERO mode
Opting in for HiDPI pixel scaling
Prism pipeline name = com.sun.prism.es2.ES2Pipeline
Loading ES2 native library ... prism_es2
succeeded.
GLFactory using com.sun.prism.es2.X11GLFactory
(X) Got class = class com.sun.prism.es2.ES2Pipeline
Initialized prism pipeline: com.sun.prism.es2.ES2Pipeline

What clearly suggests ES2 pipeline usage. While, when tested the following:

        println("Is ES2? ${Prism.isES2()}")
        println("Is D3D? ${Prism.isD3D()}")
        println("Is SW? ${Prism.isSW()}")

I do get all set to "false"

The problematic lines for prism pipeline selection are located in the "org.eclipse.fx.drift.internal.prism.Prims" class

String name = iDefaultResourceFactory.getClass().getName();
isD3D = "com.sun.prism.d3d.D3DResourceFactory".equals(name);
isES2 = "com.sun.prism.es2.ES2ResourceFactory".equals(name);
isSW = "com.sun.prism.sw.SWResourceFactory".equals(name);

Edit:
It looks like for some reason the static initialization of "BaseDriftFXSurface" class failed and
the "Prism.initialize()" function hasn't been called. Once I have manually invoked this DriftFx correctly
recognizes the ES2 pipline.

@redrezo
Copy link
Member

redrezo commented Mar 18, 2021

@wgryglas

It looks like for some reason the static initialization of "BaseDriftFXSurface" class failed and
the "Prism.initialize()" function hasn't been called. Once I have manually invoked this DriftFx correctly
recognizes the ES2 pipline.

This is quite strange, the static initializer should be called - if its really not called then java itself would have an issue :/
Do you get an exception from the failed static initialization? It should fail with UnsupportedOperationException("Unknown JavaFX pipeline!") if it cannot find any pipeline.
The only thing that comes to my mind is that maybe when you load the class your current class loader is not able to find the internal javafx classes.
What Java Version are you using? And which ClassLoader / Thread creates your DriftFXSurface Instance? And which ClassLoader / Thread calls Prism.initialize() when it works.
Also please add the Drift Version you are using when reporting an issue

@wgryglas
Copy link

@redrezo Sorry for the lack of description of my configuration.
I was running it with Java 11 OpenJDK, Java FX 11 (with necessary modules opened) and 1.0.0.rc4 release of DriftFx.
The DriftFxSurface was created in the main JavaFX thread, and in the same thread the Prism.initilize() was called.

As it looked strange to me that static initialization was not called I have tried to clean the project with gradle cleanJava task, but this hasn't resolved the issue. However, after some work and tests of different configurations, right now it looks like the program runs well even without explicit Prism.initialize(). As I was playing around with the code (all the time Prism.initilize() was called) it is hard for me to point out what has changed that might influence the execution.

I would assume it was some strange behavior related to class loader and probably not properly cleared/recompiled classes?

Currently, it looks like the problem does not exist. I will be working on it for some time and if I will come across this issue once again I will try to prepare a project with a valid code reproducing the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants