Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » e(fx)clipse » Eclipse RCP + DriftFX(Integration of OpenGL content inside an Eclipse RCP application by using DriftFX)
Eclipse RCP + DriftFX [message #1851572] Fri, 08 April 2022 17:50 Go to next message
Damiano Fabiani is currently offline Damiano FabianiFriend
Messages: 9
Registered: April 2022
Junior Member
Hi,
I am new in the Eclipse forum but I have been working with Eclipse IDE and Eclipse RCP applications for many years.
Recently, I am evaluating the integration of OpenGL content inside an RCP application built with JavaFX. For this purpose, I am going to use the DriftFXSurface object coming from the DriftFX project.


First of all, since on the DriftFX GitHub repository I noticed that the last commit is about 15 months ago, if possible I would like to know if the project is still active and if there is a plan for a production ready release.


Then, I need some help for using DriftFX in my test RCP application. Actually I am using Eclipse IDE 2021-12 with e(fx)clipse 3.7.0 plugin, OpenJDK 17 and OpenJFX 17. In my target platform I added the software site for the DriftFX 1.0.0.rc4 release.
I put the org.eclipse.fx.drift plugin in the dependencies of my test bundle and also in the feature I use to launch my test product. When the application starts, I get the following exception coming from the class using DriftFX objects:

java.lang.IllegalAccessError: superclass access check failed: class org.eclipse.fx.drift.internal.DriftHelper (in unnamed module @0x7fb02606) cannot access class com.sun.javafx.scene.NodeHelper (in module javafx.graphics) because module javafx.graphics does not export com.sun.javafx.scene to unnamed module @0x7fb02606

I suppose it could be a problem with java modules, but I have to admit I am not very skilled on this argument. What I can say is that without using any object from DriftFX, my application runs correctly with JavaFX widgets.
Do you have any suggestion about how to resolve this issue? What should I check?



Thank you very much

Damiano
Re: Eclipse RCP + DriftFX [message #1851579 is a reply to message #1851572] Fri, 08 April 2022 20:31 Go to previous messageGo to next message
Stephane  fournier is currently offline Stephane fournierFriend
Messages: 340
Registered: July 2009
Senior Member
Hi Damiano,

My e4 - efx RCP, I did not use the trick provided by EFX to integrate JavaFX in the class path though -Dosgi.framework.extensions=org.eclipse.fx.osgi

I do prefer pointing to a folder where OpenJFX is installed (shared between many apps)
Then I pass the options for JavaFX as in a standard java+javafx app.

Why am i doing that ?
To have other tools running as usual : ScenicView can connect easily, JFX WebView is rendering correctly no class path exceptions etc....
I posted, sometimes ago, about that: https://www.eclipse.org/forums/index.php/t/1108374/

Drawback: deployment is not also simple as using the bundles.

To get the solution running, you have to remove the efx osgi fragment tour app and -Dosgi.framework.extensions=org.eclipse.fx.osgi from launch args.


Here is an example to get JavaFX running with ControlsFX libs for instance.

Maybe you can give it a try and then reduce the add-export entries to get the minimal ones you need.

Very interested in news about DriftFX that looks promising and no news for a while.
Another option is to use JxBrowser widget that enables WebGL.

--module-path=pathTo/javafx-sdk-15.0.1/lib
--add-modules=javafx.graphics --add-modules=javafx.controls --add-modules=javafx.fxml --add-modules=javafx.web --add-modules=javafx.swing --add-exports=javafx.graphics/javafx.scene=ALL-UNNAMED --add-exports=javafx.graphics/com.sun.javafx.scene=ALL-UNNAMED --add-exports=javafx.graphics/com.sun.javafx.scene.traversal=ALL-UNNAMED --add-exports=javafx.graphics/com.sun.javafx.css=ALL-UNNAMED --add-exports=javafx.graphics/javafx.css=ALL-UNNAMED --add-exports=javafx.graphics/com.sun.javafx.application=ALL-UNNAMED --add-exports=javafx.graphics/com.sun.glass.ui=ALL-UNNAMED --add-exports=javafx.graphics/com.sun.javafx.stage=ALL-UNNAMED --add-exports=javafx.base/javafx.event=ALL-UNNAMED --add-exports=javafx.base/javafx.collections=ALL-UNNAMED --add-exports=javafx.base/com.sun.javafx.event=ALL-UNNAMED --add-exports=javafx.base/com.sun.javafx.collections=ALL-UNNAMED --add-exports=javafx.base/com.sun.javafx.runtime=ALL-UNNAMED --add-exports=javafx.base/com.sun.javafx.binding=ALL-UNNAMED --add-exports=javafx.controls/javafx.scene.control=ALL-UNNAMED --add-exports=javafx.controls/com.sun.javafx.scene.control=ALL-UNNAMED --add-exports=javafx.controls/com.sun.javafx.scene.control.behavior=ALL-UNNAMED --add-exports=javafx.controls/com.sun.javafx.scene.control.inputmap=ALL-UNNAMED

Damiano Fabiani wrote on Fri, 08 April 2022 19:50
Hi,
I am new in the Eclipse forum but I have been working with Eclipse IDE and Eclipse RCP applications for many years.
Recently, I am evaluating the integration of OpenGL content inside an RCP application built with JavaFX. For this purpose, I am going to use the DriftFXSurface object coming from the DriftFX project.


First of all, since on the DriftFX GitHub repository I noticed that the last commit is about 15 months ago, if possible I would like to know if the project is still active and if there is a plan for a production ready release.


Then, I need some help for using DriftFX in my test RCP application. Actually I am using Eclipse IDE 2021-12 with e(fx)clipse 3.7.0 plugin, OpenJDK 17 and OpenJFX 17. In my target platform I added the software site for the DriftFX 1.0.0.rc4 release.
I put the org.eclipse.fx.drift plugin in the dependencies of my test bundle and also in the feature I use to launch my test product. When the application starts, I get the following exception coming from the class using DriftFX objects:

java.lang.IllegalAccessError: superclass access check failed: class org.eclipse.fx.drift.internal.DriftHelper (in unnamed module @0x7fb02606) cannot access class com.sun.javafx.scene.NodeHelper (in module javafx.graphics) because module javafx.graphics does not export com.sun.javafx.scene to unnamed module @0x7fb02606

I suppose it could be a problem with java modules, but I have to admit I am not very skilled on this argument. What I can say is that without using any object from DriftFX, my application runs correctly with JavaFX widgets.
Do you have any suggestion about how to resolve this issue? What should I check?



Thank you very much

Damiano

Re: Eclipse RCP + DriftFX [message #1851644 is a reply to message #1851579] Mon, 11 April 2022 15:58 Go to previous messageGo to next message
Damiano Fabiani is currently offline Damiano FabianiFriend
Messages: 9
Registered: April 2022
Junior Member
Ok, thanks to Stephane suggestions, it seems I resolved my issue and javafx.graphics pacakages are reachable at runtime in my test application.

Unfortunately, now I have another problem, strictly related to DriftFX.
I followed the DriftFX java usage example from the GitHub page, so I have created a GLContext with JOGL, which is the OpenGL Java wrapper I have always used; then, when I call the createSwapchain method from the Renderer object, I get the following exception:

java.lang.RuntimeException: null
at org.eclipse.fx.drift.internal.frontend.FxImageFactory.createFxImage(FxImageFactory.java:37) ~[na:na]
at org.eclipse.fx.drift.internal.frontend.SimpleFrontSwapChain.<init>(SimpleFrontSwapChain.java:58) ~[na:na]
at org.eclipse.fx.drift.internal.frontend.FrontendImpl.doCreateSwapchain(FrontendImpl.java:99) ~[na:na]
at org.eclipse.fx.drift.internal.frontend.FrontendImpl.receiveCommand(FrontendImpl.java:137) ~[na:na]
at org.eclipse.fx.drift.internal.backend.BackendImpl.sendCommand(BackendImpl.java:85) ~[na:na]
at org.eclipse.fx.drift.internal.backend.BackendImpl.createSwapchain(BackendImpl.java:45) ~[na:na]
at org.eclipse.fx.drift.internal.RendererImpl.createSwapchain(RendererImpl.java:88) ~[na:na]

The exception log is preceded by some text information about the GLContext used, which are the following:

[C] OpenGL Context information "Dummy Context"
[C] Version: 4.6.0 NVIDIA 442.92
[C] Vendor: NVIDIA Corporation
[C] Renderer: Quadro K2000/PCIe/SSE2
[C] OpenGL Context information "Function Pointer Resolving Context"
[C] Version: 4.5.0 NVIDIA 442.92
[C] Vendor: NVIDIA Corporation
[C] Renderer: Quadro K2000/PCIe/SSE2

What am I missing? Has someone used DriftFX together with JOGL? Which is the correct way for creating a GLContext and use it with the DriftFXSurface and its related Swapchain?
Re: Eclipse RCP + DriftFX [message #1851647 is a reply to message #1851644] Mon, 11 April 2022 16:39 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6651
Registered: July 2009
Senior Member
I don't think we have JOGL-Base samples - we only have samples for LWJGL - https://github.com/BestSolution-at/efxclipse-drift-samples
Re: Eclipse RCP + DriftFX [message #1851670 is a reply to message #1851647] Tue, 12 April 2022 07:57 Go to previous messageGo to next message
Damiano Fabiani is currently offline Damiano FabianiFriend
Messages: 9
Registered: April 2022
Junior Member
Hi Tom,
from your link I looked at the examples with LWJGL and I focused on the GLContext creation. I want to reproduce a similar logic using JOGL and see if it works.

I was trying to create a GLContext and make it current like in the examples with the following two lines of code:

long ctx = org.eclipse.fx.drift.internal.GL.createContext(0, 3, 0);
org.eclipse.fx.drift.internal.GL.makeContextCurrent(ctx);

The problem now is that I get the message "Access restriction: The type 'GL' is not API" from the Eclipse IDE and I cannot call those two methods. I saw that in the org.eclipse.fx.drift bundle (which I obtained by linking the DriftFX release software site in my target platform) the org.eclipse.fx.drift.internal package is not listed in the exported packages.
Is it possible to follow the examples logic also in an Eclipse RCP environment? How can I do it?

Many thanks
Re: Eclipse RCP + DriftFX [message #1851716 is a reply to message #1851670] Wed, 13 April 2022 13:54 Go to previous messageGo to next message
Damiano Fabiani is currently offline Damiano FabianiFriend
Messages: 9
Registered: April 2022
Junior Member
Hi,
I spent the last two days testing JOGL and DriftFX interaction, and I am glad to say that it works!

I started from the examples linked by Tom. As explained in my previous message, I could not create an OpenGL context using classes from the internal package of the drift bundle, but there is no need to do that. I found the GLContext can be created and made current using JOGL methods only.

For those who want to use DriftFX with JOGL, you can use the following lines of code for creating the GLContext:
GLProfile glProfile = GLProfile.getMaxFixedFunc(true);
GLCapabilities glCapabilities = new GLCapabilities(glProfile);

GLAutoDrawable dummyDrawable = GLDrawableFactory.getFactory(glProfile).createDummyAutoDrawable(null, true, glCapabilities, null);
dummyDrawable.display();

GLContext ctx = dummyDrawable.getContext();
ctx.makeCurrent();

After that, it is possible to build the DriftFX Swapchain and then render to a FBO using the JOGL API. The logic is very similar to the LWJGL examples.
I tested it putting the DriftFXSurface in a pure JavaFX Stage and also in a FXCanvas (SWT bridge).

For me the DriftFX project is very interesting. When possible, I would really like to know if there is a roadmap for improvements and a stable release after the current RC4.

Thank you very much
Re: Eclipse RCP + DriftFX [message #1851763 is a reply to message #1851716] Fri, 15 April 2022 07:26 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6651
Registered: July 2009
Senior Member
Well from our point of view DriftFX is stable. Yes we haven't yet released a 1.0 but that's more a priority thing on our side. BTW integrating via FXCanvas is from a performance point of view the worst you can do (you grab there the JavaFX-Pixels and copy them as an SWT-Image). As you can integrate OpenGL natively in the SWT I think that would be the better approach.
Re: Eclipse RCP + DriftFX [message #1851766 is a reply to message #1851763] Fri, 15 April 2022 07:39 Go to previous messageGo to next message
Damiano Fabiani is currently offline Damiano FabianiFriend
Messages: 9
Registered: April 2022
Junior Member
Ok Tom, glad to hear that DriftFX is considered stable.
I started to build a little engine with JOGL, rendering on a DriftFXSurface in an Eclipse RCP application. I am doing that in pure JavaFX without SWT bridge. When possible, I will update you about the results I will reach (performance etc.)

Thank you very much.
Re: Eclipse RCP + DriftFX [message #1851943 is a reply to message #1851766] Fri, 22 April 2022 10:51 Go to previous messageGo to next message
Damiano Fabiani is currently offline Damiano FabianiFriend
Messages: 9
Registered: April 2022
Junior Member
Hi,
during the last few days I could test DriftFX in my RCP environment.
What I did is to build a test app with only a Part containing a DriftFXSurface where I render a textured quad. It is possible to make pan and zoom actions on the textured quad and multiple Parts of the described type can be opened.
There is a single thread which manages the OpenGL context and renders into all the opened DriftFXSurfaces. My focus was on the FPS I can reach with this structure, trying both MainMemory and NVDXInterop transfer types.

MainMemory
When the Part has a small size, FPS are stable to 60 (I suppose the DriftFX Swapchain uses the screen vertical synchronization). If I enlarge the Part, or set it fullscreen or open other Parts of the same type, the FPS decrease. It seems FPS are inversely related to the overall surface covered by the opened Parts. I think this is an expected behaviour and I've experimented no other issues with this transfer type.

NVDXInterop
When the Part has a small size, FPS are stable to 60. If I enlarge the Part, or set it fullscreen or open other Parts of the same type, I see a strange behaviour: the FPS checked on my rendering thread seems to increase but a great latency in displaying the frames is present. I noted this behaviour by trying pan and zoom and seeing that the results of the actions are displayed with a great delay. The latency seems to be related to the overall surface covered by the opened Parts. Moreover, if I resize the Parts when they are in this "delayed" state, the re-recreation of the DriftFX Swapchain takes several time and freezes the rendering thread for a while.

For completeness, I give you my PC specs

  • Screen resolution: 2560x1440
  • GPU: NVIDIA QUADRO K2000
  • CPU: Intel Xeon E3-1240 V2 - 3.40GHz


Are the experimented behaviours with both transfer types somehow expected? Is there some best usage for improving performances?

Many thanks.
Re: Eclipse RCP + DriftFX [message #1852172 is a reply to message #1851943] Tue, 03 May 2022 14:40 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6651
Registered: July 2009
Senior Member
I pasted your question to the guy who did all the implementation.
Re: Eclipse RCP + DriftFX [message #1852177 is a reply to message #1851572] Tue, 03 May 2022 16:48 Go to previous messageGo to next message
Christoph Caks is currently offline Christoph CaksFriend
Messages: 10
Registered: July 2009
Junior Member
JavaFX is by default capped but your renderthread could theoretically render at some 1000FPS. This causes enormous load on the gpu and overall reaction time may suffer. Try to cap your renderthread fps.
If you create your swap chain with only 2 images this backpressure can be automatically handled. The acquire() call is blocking until a texture is available. This causes your renderthread to run with the same framerate as javafx. (javafx always owns one texture and releases it once it gets a new texture with present(), so you can only acquire a new texture after javafx did a frame)

also there is a debug flag (-Ddriftfx.showfps=true) which renders the fps onto the surfaces.

MainMemory:
The performance impact of bigger surfaces in MainMemory is expected. Since for each frame the buffer needs to be downloaded from video memory, and uploaded again.

NVDXInterop:
The pixel transfer happens purely on the GPU. I think the performance impact has something to do with your render thread speeding up. It could be also caused by recreating swapchains like crazy, because if you used 2 images like descriped above and re-create a swapchain for every pixel you resize it could render 2 frames into the new buffer for every resize..

The swapchain (re-)creation is an expensive operation. The textures need to be allocated and the NVDXInterop stuff needs to be set up.
I would recommend to minimize the re-creation of your swapchains.
Either you could create bigger surfaces that only need recreation if your part gets bigger than it, or you could even share one buffer and split it into areas for your parts.
I usally added a timeout like some 100ms where the new size needs to be stable before resizing the swap chains, this drastically reduces resize operations.

Also I'm happy to see that somebody got it working with JOGL, theoretically it should but i never tried ;-)

If you like to you could share your code so we can add it to the samples repo (https://github.com/bestSolution-at/efxclipse-drift-samples)

[Updated on: Tue, 03 May 2022 18:27]

Report message to a moderator

Re: Eclipse RCP + DriftFX [message #1852199 is a reply to message #1852177] Wed, 04 May 2022 15:25 Go to previous messageGo to next message
Damiano Fabiani is currently offline Damiano FabianiFriend
Messages: 9
Registered: April 2022
Junior Member
Hi Cristoph,
thank you for the explanation.

I followed your suggestions and I added a timeout logic of 100 ms for reducing swapchains recreations; that has improved the performance on resize operations.
However, with large surfaces (full screen for example), the NVDXInterop transfer mode has still a strange behaviour. Using the debug flag you suggested, I see FPS are stable to 60, but it seems like GPU commands are consumed slower than my render thread frame rate. I supposed this because, if I do pan or zoom operations on the surface, I continue to see the resulting frames after some delay (some seconds). This same behaviour does not occur if I work with smaller surfaces, so I think it could be related to the amount of transferred pixels, even if the pixel transfer happens on the GPU.

Tell me if I said something wrong in the above reasoning.
Have you ever tried DriftFX with screen resolutions greater than 1920x1080 or similar? Is there something else I could check?

Since actually my test code is spread on different classes, I am trying to organize it to share a clear DriftFX+JOGL example as soon as possible.
Re: Eclipse RCP + DriftFX [message #1852233 is a reply to message #1852199] Thu, 05 May 2022 13:56 Go to previous messageGo to next message
Christoph Caks is currently offline Christoph CaksFriend
Messages: 10
Registered: July 2009
Junior Member
The input to frame latency you describe seems way to high for me.
I just started the samples and tested it on a 4k screen with a Quadro T2000 (mobile).
Once maximized the actual resolution of the surface is 3640x1668 the fps go down to 20-30 and there is a slight delay compared to small resolutions
I used the wavefront obj demo, since its the only demo where the mouse input is used for rendering. It maps the mouse position to the rotation of the object.

The same sample on the Intel(R) UHD Graphics 630 has its fps at 10-20 and the delay feels longer than on the quadro

I don't think those delays were more than 100-200ms but after a quick google i found that your K2000 is 6 years older than my T2000, so it may be reasonable that you experience a second delay there.

Did you limit / sync your renderthread framerate to the fx framerate?

Re: Eclipse RCP + DriftFX [message #1852264 is a reply to message #1852233] Fri, 06 May 2022 12:43 Go to previous messageGo to next message
Damiano Fabiani is currently offline Damiano FabianiFriend
Messages: 9
Registered: April 2022
Junior Member
Yes, my renderthread has same FPS than JavaFX.

As I promised, below there is a simple test code with JOGL and DriftFX. It opens a Stage containing a DriftFXSurface, where a basic grey rectangle is drawn. It is possible to move the rectangle by dragging the mouse left button. The TransferType can be changed by modifying the "transferType" class field.

import java.awt.Point;

import org.eclipse.fx.drift.DriftFXSurface;
import org.eclipse.fx.drift.GLRenderer;
import org.eclipse.fx.drift.PresentationMode;
import org.eclipse.fx.drift.RenderTarget;
import org.eclipse.fx.drift.Renderer;
import org.eclipse.fx.drift.StandardTransferTypes;
import org.eclipse.fx.drift.Swapchain;
import org.eclipse.fx.drift.SwapchainConfig;
import org.eclipse.fx.drift.TransferType;
import org.eclipse.fx.drift.Vec2i;

import com.jogamp.opengl.GL;
import com.jogamp.opengl.GL2;
import com.jogamp.opengl.GLAutoDrawable;
import com.jogamp.opengl.GLCapabilities;
import com.jogamp.opengl.GLContext;
import com.jogamp.opengl.GLDrawableFactory;
import com.jogamp.opengl.GLException;
import com.jogamp.opengl.GLProfile;
import com.jogamp.opengl.glu.GLU;

import it.elman.utils.Utils;
import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.layout.BorderPane;
import javafx.stage.Stage;



public class TestJOGL extends Application {
	
	private static final TransferType transferType = StandardTransferTypes.MainMemory;
	
	private static GLContext glContext;
	
	private static Thread renderThread;
	
	private static Renderer renderer;
	
	private static Swapchain swapchain;
	
	private static int[] fboIDs = new int[1];
	
	private static int[] renderTextureIDs = new int[1];
	
	private static Vec2i lastSize;
	
	private static Long lastResizeTime;
	
	private static BorderPane borderPane;
	
	private static float minX = -100;
	
	private static float maxX = 100;
	
	private static float minY = -100;
	
	private static float maxY = 100;
	
	private static Point lastMousePoint;
	
	
	public static void main(String[] args) {
		launch(args);
	}
	
	
	@Override
	public void start(Stage primaryStage) throws Exception {
		initialize();
		
		DriftFXSurface surface = new DriftFXSurface();
		renderer = GLRenderer.getRenderer(surface);
		
		borderPane = new BorderPane(surface);
		
		borderPane.setOnMouseMoved(event -> {
			
			if(lastMousePoint != null) {
				lastMousePoint.x = (int)event.getX();
				lastMousePoint.y = (int)event.getY();
			}
			else {
				lastMousePoint = new Point((int)event.getX(), (int)event.getY());
			}
			
		});
		
		borderPane.setOnMouseDragged(event -> {
			float xDrag = - (float) ((event.getX() - lastMousePoint.x)*(maxX - minX)/borderPane.widthProperty().floatValue());
			float yDrag = (float) ((event.getY() - lastMousePoint.y)*(maxY - minY)/borderPane.heightProperty().floatValue());
			
			lastMousePoint.x = (int)event.getX();
			lastMousePoint.y = (int)event.getY();
			
			if(!event.isSecondaryButtonDown()) {
				minX += xDrag;
				maxX += xDrag;
				minY += yDrag;
				maxY += yDrag;
			}
			
		});
		
		Scene scene = new Scene(borderPane);
		
		Stage stage = new Stage();
		stage.setScene(scene);
		stage.show();
		
		renderThread.start();
	}
	
	
	private static void initialize() {
		GLProfile.initSingleton();
		
		GLProfile glProfile = null;
		
		try {
			glProfile = GLProfile.getMaxFixedFunc(true);
		} catch(GLException ex) {
			ex.printStackTrace();;
		}
		
		if(glProfile == null) {
			glProfile = GLProfile.getMaxFixedFunc(false);
		}
		
		GLCapabilities glCapabilities = new GLCapabilities(glProfile);
		GLAutoDrawable dummyDrawable = GLDrawableFactory.getFactory(glProfile).createDummyAutoDrawable(null, true, glCapabilities, null);
		dummyDrawable.display();
		glContext = dummyDrawable.getContext();
		
		System.out.println("GL Profile: " + glProfile.getImplName());
		System.out.println("GL VERSION: " + glContext.getGLVersion());
		
		renderThread = new Thread("Render Thread") {
			
			@Override
			public void run() {
				
				try {
				
					while(true) {
						display();
						Thread.sleep(1);
					}
				
				} catch (InterruptedException e) {
					e.printStackTrace();
				}
				
			}
			
		};
		
		renderThread.setDaemon(true);
	}
	
	
	private static void display() {
		glContext.makeCurrent();
		
		if(fboIDs[0] == 0) {
			createFBO();
		}
		
		checkSwapchain();
		
		try {
		
			if(swapchain != null && lastResizeTime == null) {
				RenderTarget target = swapchain.acquire();
				
				renderTextureIDs[0] = GLRenderer.getGLTextureId(target);
				
				attachFBOToTexture();
				
				bindFBO();
					
				render();
				
				unbindFBO();
				
				swapchain.present(target);
			}
		
		} catch (InterruptedException e) {
			e.printStackTrace();
		}
		
		glContext.release();
	}
	
	
	private static void checkSwapchain() {
		long now = Utils.getNowInMillis();
		Vec2i size = renderer.getSize();
		
		if(size.x > 0 && size.y > 0) {
			
			if(lastSize == null || size.x != lastSize.x || size.y != lastSize.y) {
				lastResizeTime = now;
			}
			
		}
		
		lastSize = size;
		
		if(lastResizeTime != null && (now - lastResizeTime) > 100) {
			
			if (swapchain != null) {
				swapchain.dispose();
			}
			
			renderTextureIDs[0] = 0;
			
			swapchain = renderer.createSwapchain(new SwapchainConfig(size, 2, PresentationMode.MAILBOX, transferType));
			
			lastResizeTime = null;
		}
		
	}
	
	
	private static void createFBO() {
		GL2 gl = glContext.getGL().getGL2();
		gl.glGenFramebuffers(1, fboIDs, 0);
	}
	
	
	private static void attachFBOToTexture() {
		GL2 gl = glContext.getGL().getGL2();
		
		if(fboIDs[0] != 0 && renderTextureIDs[0] != 0) {
			gl.glBindFramebuffer(GL2.GL_FRAMEBUFFER, fboIDs[0]);
				
			gl.glFramebufferTexture2D(GL2.GL_FRAMEBUFFER, GL2.GL_COLOR_ATTACHMENT0, GL2.GL_TEXTURE_2D, renderTextureIDs[0], 0);
			
			int tError = gl.glCheckFramebufferStatus(GL2.GL_FRAMEBUFFER);
			
			switch(tError) {
			
				case GL.GL_FRAMEBUFFER_COMPLETE:
					break;
					
				case GL.GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT:
					System.err.println("FRAMEBUFFEROBJECT CHECK RESULT = GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT");
					break;
					
				case GL.GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT:
					System.err.println("FRAMEBUFFEROBJECT CHECK RESULT = GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT");
					break;
					
				case GL.GL_FRAMEBUFFER_INCOMPLETE_DIMENSIONS:
					System.err.println("FRAMEBUFFEROBJECT CHECK RESULT = GL_FRAMEBUFFER_INCOMPLETE_DIMENSIONS");
					break;
					
				case GL.GL_FRAMEBUFFER_INCOMPLETE_FORMATS:
					System.err.println("FRAMEBUFFEROBJECT CHECK RESULT=GL_FRAMEBUFFER_INCOMPLETE_FORMATS_EXT");
					break;
					
				case GL2.GL_FRAMEBUFFER_INCOMPLETE_DRAW_BUFFER:
					System.err.println("FRAMEBUFFEROBJECT CHECK RESULT = GL_FRAMEBUFFER_INCOMPLETE_DRAW_BUFFER");
					break;
					
				case GL2.GL_FRAMEBUFFER_INCOMPLETE_READ_BUFFER:
					System.err.println("FRAMEBUFFEROBJECT CHECK RESULT = GL_FRAMEBUFFER_INCOMPLETE_READ_BUFFER");
					break;
					
				case GL.GL_FRAMEBUFFER_UNSUPPORTED:
					System.err.println("FRAMEBUFFEROBJECT CHECK RESULT = GL_FRAMEBUFFER_UNSUPPORTED");
					break;
					
				default:
					System.err.println("FRAMEBUFFER CHECK RETURNED UNKNOWN RESULT ...");
					break;
			}
				
			gl.glBindFramebuffer(GL2.GL_FRAMEBUFFER, 0);
		}
		
	}
	
	
	private static void bindFBO() {
		GL2 gl = glContext.getGL().getGL2();
		gl.glBindFramebuffer(GL2.GL_FRAMEBUFFER, fboIDs[0]);
	}
	
	
	private static void unbindFBO() {
		GL2 gl = glContext.getGL().getGL2();
		gl.glBindFramebuffer(GL2.GL_FRAMEBUFFER, 0);
	}
	
	
	private static void render() {
		GL2 gl = glContext.getGL().getGL2();
		GLU glu = new GLU();
		
		gl.glViewport(0, 0, borderPane.widthProperty().intValue(), borderPane.heightProperty().intValue());
		
		gl.glMatrixMode(GL2.GL_PROJECTION);
		gl.glLoadIdentity();
		
		glu.gluOrtho2D(minX, maxX, minY, maxY);
		
		gl.glMatrixMode(GL2.GL_MODELVIEW);
		gl.glLoadIdentity();
		
		gl.glColorMask(true, true, true, true);
		gl.glClearColor(0f, 0f, 0f, 1f);
		gl.glClear(GL.GL_COLOR_BUFFER_BIT);
		gl.glColorMask(true, true, true, false);
		
		gl.glColor3f(0.6f, 0.6f, 0.6f);
		
		gl.glBegin( GL2.GL_QUADS);
			gl.glVertex3f(-90f, -90f, 0);
			gl.glVertex3f(-90f, 90f, 0);
			gl.glVertex3f(90f, 90f, 0);
			gl.glVertex3f(90f, -90f, 0);
		gl.glEnd();
	}


}


By running it in NVDXInterop mode and looking at the Windows Task Manager, I have experimented the following behaviour: the GPU usage increases if I enlarge the Stage; moreover, the GPU usage changes also in relation to the amount of grey rectangle area drawn on the surface (which can be changed with mouse drag). This last observation is very strange, I don't know if it can be related to the DirectX internal texture transfer, but it does not occur in MainMemory mode.
However, I found that when I see the frame latency in NVDXInterop mode, the GPU usage is almost 100%; the renderthread is always at 60 FPS, so I suppose in that state the OpenGL commands are enqueued but the GPU does not have the capability to consume them at the same rate. This could be the reason of the delay/latency I see; I suppose the internal DirectX texture transfer is not a light operation and maybe with my graphic card the performance suffers.

By the way, you can run the JOGL sample I posted. You have only to resolve the dependencies with JOGL (I used the 2.3.2 version).
If you think it is useful, you can add it to the samples repo. Also, if you find some time to test it, let me know if you experience the same behaviours I described.

Thank you for your time.
Re: Eclipse RCP + DriftFX [message #1852266 is a reply to message #1852264] Fri, 06 May 2022 13:31 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6651
Registered: July 2009
Senior Member
Maybe I read that code wrong but if you sleep 1ms you are running with 1000 FPS not? To run at 60fps you need to sleep 1000ms/60 = 16ms or am I completely mistaken.
Re: Eclipse RCP + DriftFX [message #1852269 is a reply to message #1852266] Fri, 06 May 2022 14:00 Go to previous message
Damiano Fabiani is currently offline Damiano FabianiFriend
Messages: 9
Registered: April 2022
Junior Member
Yes Tom, that's what I thought at first, but then I saw my FPS was stable to 60, automatically synchronized with JavaFX and vertical synch. Using the "-Ddriftfx.showfps=true" flag, I had the same results.
I was able to modify this behaviour only by adding the "-Dprism.vsync=false" flag (which by default has "true" value). In that case my renderthread runs at its maximum speed, but I abandoned that way because I preferred to have 60 stable FPS.

If you can test the sample and find a different behaviour than mine, let me know. Thanks.
Previous Topic:EFX Tooling and Runtime 2022 release plan ?
Next Topic:e(fx)clipse - 3.8.0 has been released
Goto Forum:
  


Current Time: Tue Oct 15 03:37:21 GMT 2024

Powered by FUDForum. Page generated in 0.07229 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top