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 |
Damiano Fabiani 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 |
Stephane fournier 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:50Hi,
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 |
Damiano Fabiani 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 #1851716 is a reply to message #1851670] |
Wed, 13 April 2022 13:54 |
Damiano Fabiani 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 #1851943 is a reply to message #1851766] |
Fri, 22 April 2022 10:51 |
Damiano Fabiani 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 #1852177 is a reply to message #1851572] |
Tue, 03 May 2022 16:48 |
Christoph Caks 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 |
Damiano Fabiani 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 #1852264 is a reply to message #1852233] |
Fri, 06 May 2022 12:43 |
Damiano Fabiani 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.
|
|
| | |
Goto Forum:
Current Time: Sat Nov 09 01:51:56 GMT 2024
Powered by FUDForum. Page generated in 0.05597 seconds
|