Empty DFX pane, maybe depending on exact execution timings

[ReikaKalseki]

I have returned to using DriftFX to have custom OGL rendering inside JavaFX windows, and have run into some odd behavior that resembles something I described in a past comment.

Before I describe my experience right now, let me describe what I have experienced in the intervening months using DFX, as it may well be relevant:

• There appears to be a very narrow window during which it is valid to initialize DFX relative to JFX, and with these operating largely independently, this is ultimately relying on a race condition. In particular, I have the DriftFXSurface in my GUI Controller class along with the other "named" FXML elements, and it is initialized as that controller is built. The GLRenderer.getRenderer() call is then performed on that surface, waiting on it to be non-null if the JFX initialization has not yet constructed it. However, delaying or accelerating the JFX initialization nonetheless seems to break this system. This may be related to the next two points.
• The surface seems to often initialize with a size of zero if the timing is wrong, resulting in a useless renderer. I can simply defer the createSwapchain calls until this is nonzero, but that never appears to occur if it does initialize with zero.
• Forcibly recreating new swapchains does not appear to work as expected; intuitively I expected, perhaps wrongly, that I can arbitrarily discard the old chain and request a new one, but while the actual swapchain request does seem to work, the result is an empty renderer. I seem to recall one of your examples having a dropdown to choose the TransferType, the changing of which requires a new swapchain, so I am somewhat puzzled as to what is going wrong here.

At any rate, at the present, I have for the first time tried exporting my project out of eclipse into a standalone jar file. After some pain getting JFX and lwjgl to work, I promptly experienced a functional JFX GUI but with an empty DFX render pane, alongside the warning that the size of the render surface was zero (and thus we should expect point 2 above to apply).

This may all be due to error(s) on my part, or there might be an actual issue here.

Here is my actual render loop, which handles both the DFX initialization (based on the surface in the GuiController) and the drawing on said surface: https://github.com/ReikaKalseki/GameCalendar/blob/master/src/Reika/GameCalendar/Rendering/RenderLoop.java

[pavel-ruban]

Any info on this one? I saw your sibling comments with calendar app example which I used as a blueprint and it flawesly works in windows context with d3d nxv (don't recall the exact name) swapchain target. However when I use it on Linux with main memory target my results same as yours, empty black pane or sometimes like some race condition ( but code is like yours with two threads and working fine on windows) it shows the content of my gl render calls and flickering with black like crazy, very rare it's good non flicking gl image but in all cases it's stuck, not updating despite thread works, acquire and framebuffers and textures are ok. It seems there is some issue with that surface drift fx texture aquire. Initially I though it could be vbox as I test it there but all other gl apps work fine, I switched to native env - same behavior, I'm on latest arch Linux, Nvidia 1080 ti, tried noveau, Nvidia and Nvidia dkms drivers no change. Fx is forced to GPU usage es2 pipeline is found by prism, when I call same gl commands as with windows I don't have any gl error, logs or exceptions. Will try to debug swapchain aquire method further as I believe the problem somewhere there. I had plenty errors with missing add-opens for fx graphic module but it also was fixed and windows started working (but at that stage I had error logs during runtime, now it's like it should work but pane is dead black in 93%, 6% flickering with such content and 1% good but stuck gl image, I just rerun the program until it shown)

I tried your calendar workaround to get gl context with glfw, but it's same, switched back to drift method, tried core and compatibility gl profiles. Starting to get lack of ideas.

[pavel-ruban]

Some new info:

• I did some experements and put gl context & chain initial creation into javafx app thread right after window.show, as by that time gtk still didnt open window & drift surface wasnt shown, its size was 0, so i just manually put default values for swapchain creation, i did standard stuff, put glclear with colors to newrly inited fbo with attached surface texture to it & had to put gl context initialization prior, happened several things:
• i got few exception on drift node creation i hadn't visible before by some reason, fixed with : --add-opens javafx.graphics/com.sun.prism.impl=ALL-UNNAMED --add-opens javafx.graphics/com.sun.prism.es2=ALL-UNNAMED
• my surface started to stably rendering my glclear color frame on every app run.
• then i tried to share swapchain and the rest stuff with my render thread, i had to again create a gl context there & surface again started to flickering black with my gl color (I change it once per 50 frames & its updated on surface node but its flickering like crazy despite correct every frame chain acquire & fbo texture binding (which is jumping between 1 & 2 every frame, but thats ok as its same in windows & it works there fine)
• When i try acquire drift texture from another thread as in previous thread apart of flickering i often see linux gui frames in my surface node & it segfaults pretty often once per 30-60 secs.
• If I comment out the renderer thread and keep one frame gl color logic in fx thread, the surface is rock stable, no flickering just correct color rendered to fx window, the issue though that I need to decouple my custom rendering from fx thread so I don't block it, it's events etc.

I come to conclusion that in linux there are some rules regarding thread contexts & memory managment, so im trying to find a way to handle it safely. I tried to create a shared gl context with gl context id from fx thread where i render initial frame but it segfaults immediately.

it looks like when you acquire a texture in another thread it gets reallocated by os/fx thread and many issues happen.

[pavel-ruban]

I tried to test dynamic rendering inside javafx thread with delayed callbacks & it works

import javafx.concurrent.Task;

                // fx init code here.

        for (int i = 1; i < 100; ++i) {
            int finalI = i;
            delay(100 * i, () -> {
                GL32.glBindFramebuffer(GL32.GL_FRAMEBUFFER, renderLoop.fb);
                GL32.glFramebufferTexture(GL32.GL_FRAMEBUFFER, GL32.GL_COLOR_ATTACHMENT0, tex, 0);
                GL11.glClearColor(finalI % 2 == 0 ? 1 : 0, 1, 0, 1);
                GL11.glClear(GL11.GL_COLOR_BUFFER_BIT | GL11.GL_DEPTH_BUFFER_BIT);
                renderLoop.chain.present(renderLoop.renderTarget);
            });
        }
    }

    public static void delay(long millis, Runnable continuation) {
        Task<Void> sleeper = new Task<Void>() {
            @Override
            protected Void call() throws Exception {
                try { Thread.sleep(millis); }
                catch (InterruptedException e) { }
                return null;
            }
        };
        sleeper.setOnSucceeded(event -> continuation.run());
        new Thread(sleeper).start();
    }

trying to wrap my head how to make my custom thread work

[pavel-ruban]

Some my findings:

• I managed to fix the issue on native linux but I still have glitches on Vbox linux.
• On Vbox it started to always init, no anymore black panes, however still from time to time when you init the app gl surface flicker with os gui textures & the correct app image data, also if init goes wrong, in a while it segfaults the image pipeline & vbox crashes (it only happens during init, if canvas flickering with OS image data it may crash in a while or it crashes immediately during the init, if init was ok & image rendering fine, it doesnt crash
• when it crashes the slave OS gui stucks completely, but you still can move mouse & it changes cursor icons but nothing gets updated on the screen, if you click shortcut eg to close X11 vbox client crashes with memory error & you need to reload the OS.
• on native linux now it seems it works ok. But its a big inconvinience that vbox crashes as you need to test crossplatofrm etc, at least it works partially

What helped to fix problems / improve things:

• I noted that if call renderLoop.hook = GLRenderer.getRenderer(getRenderPane()); done in main javafx quantum renderer thread the crashes & glitches happen way less often. It also works fine in native linux if its put on a separate thread but not in vbox
• Issue with black pane was due to empty surface size & initial swapchain init, even if its done after jfx thread's window.show(), gtk or other stuff still takes time to do all stuff & if you stop in debugger when you got surface visible, the window is still not shown to user & size is 0, so i ended up with while looping surface size in my side render thread to check that size finally got non 0 value, since that moment i added 300ms delay for safety & black pane issue gone
• I also avoided fbo & depth texture recration on every frame from the calendar app

Example code: Added my latest example code variant based on @ReikaKalseki calendar app here https://github.com/pavel-ruban/javafx-driftfx-opengl-canvas-example/

Seems I finished here as vbox glitches I believe are linked to memory hacks done by driftfx implementation & it conflicts with some vbox stuff or timings / threads difference ruin it. At least I could achieve both win & linux native OS result + can test it on vbox with some pain & periodic init segfault crashes. Hope one day vbox also will work stablr

Vbox info:

root@terminal ~ # uname -r                                                                                                                                             
6.6.7-arch1-1

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
Gtk-Message: 04:50:52.116: Failed to load module "rgba"
Maximum supported texture size: 16384
Maximum texture size clamped to 4096
Non power of two texture support = true
Maximum number of vertex attributes = 16
Maximum number of uniform vertex components = 16384
Maximum number of uniform fragment components = 16384
Maximum number of varying components = 124
Maximum number of texture units usable in a vertex shader = 16
Maximum number of texture units usable in a fragment shader = 16
Graphics Vendor: VMware, Inc.
       Renderer: SVGA3D; build: RELEASE;  LLVM;
        Version: 4.1 (Compatibility Profile) Mesa 23.3.1-arch1.1
 vsync: true vpipe: true
Initializing GUI.
Post-initializing GUI.
Hook init

glxgears_fbconfig

GLX 1.3 is supported.
GLX_SGIX_fbconfig is supported.

The following fbconfigs meet the requirements.  The first one will be used.

0x95        TrueColor     24   0   y   .  y    .    8  8  8  0  24  0   0  0  0  0     0     0       y       .
0xb5        TrueColor     24   0   y   .  y    .    8  8  8  0  24  0   0  0  0  0     0     0       y       .
0xe5        DirectColor   24   0   y   .  y    .    8  8  8  0  24  0   0  0  0  0     0     0       y       .
0x105       DirectColor   24   0   y   .  y    .    8  8  8  0  24  0   0  0  0  0     0     0       y       .
0x99        TrueColor     24   0   y   .  y    .    8  8  8  0  24  8   0  0  0  0     0     0       y       .
0xb9        TrueColor     24   0   y   .  y    .    8  8  8  0  24  8   0  0  0  0     0     0       y       .
0xe9        DirectColor   24   0   y   .  y    .    8  8  8  0  24  8   0  0  0  0     0     0       y       .
0x109       DirectColor   24   0   y   .  y    .    8  8  8  0  24  8   0  0  0  0     0     0       y       .
0x91        TrueColor     24   0   y   .  y    .    8  8  8  0  16  0   0  0  0  0     0     0       y       .
0xb1        TrueColor     24   0   y   .  y    .    8  8  8  0  16  0   0  0  0  0     0     0       y       .
0xe1        DirectColor   24   0   y   .  y    .    8  8  8  0  16  0   0  0  0  0     0     0       y       .
0x101       DirectColor   24   0   y   .  y    .    8  8  8  0  16  0   0  0  0  0     0     0       y       .
0x85        TrueColor     32   0   y   .  y    .    8  8  8  8  24  0   0  0  0  0     0     0       y       .
0xa5        TrueColor     32   0   y   .  y    .    8  8  8  8  24  0   0  0  0  0     0     0       y       .
0xd5        DirectColor   32   0   y   .  y    .    8  8  8  8  24  0   0  0  0  0     0     0       y       .
0xf5        DirectColor   32   0   y   .  y    .    8  8  8  8  24  0   0  0  0  0     0     0       y       .
0x89        TrueColor     32   0   y   .  y    .    8  8  8  8  24  8   0  0  0  0     0     0       y       .
0xa9        TrueColor     32   0   y   .  y    .    8  8  8  8  24  8   0  0  0  0     0     0       y       .
0xd9        DirectColor   32   0   y   .  y    .    8  8  8  8  24  8   0  0  0  0     0     0       y       .
0xf9        DirectColor   32   0   y   .  y    .    8  8  8  8  24  8   0  0  0  0     0     0       y       .
0x81        TrueColor     32   0   y   .  y    .    8  8  8  8  16  0   0  0  0  0     0     0       y       .
0xa1        TrueColor     32   0   y   .  y    .    8  8  8  8  16  0   0  0  0  0     0     0       y       .
0xd1        DirectColor   32   0   y   .  y    .    8  8  8  8  16  0   0  0  0  0     0     0       y       .
0xf1        DirectColor   32   0   y   .  y    .    8  8  8  8  16  0   0  0  0  0     0     0       y       .
0x96        TrueColor     24   0   y   .  y    .    8  8  8  0  24  0  16 16 16 16     0     0       y       .
0xb6        TrueColor     24   0   y   .  y    .    8  8  8  0  24  0  16 16 16 16     0     0       y       .
0xe6        DirectColor   24   0   y   .  y    .    8  8  8  0  24  0  16 16 16 16     0     0       y       .
0x106       DirectColor   24   0   y   .  y    .    8  8  8  0  24  0  16 16 16 16     0     0       y       .
0x9a        TrueColor     24   0   y   .  y    .    8  8  8  0  24  8  16 16 16 16     0     0       y       .
0xba        TrueColor     24   0   y   .  y    .    8  8  8  0  24  8  16 16 16 16     0     0       y       .
0xea        DirectColor   24   0   y   .  y    .    8  8  8  0  24  8  16 16 16 16     0     0       y       .
0x10a       DirectColor   24   0   y   .  y    .    8  8  8  0  24  8  16 16 16 16     0     0       y       .
0x92        TrueColor     24   0   y   .  y    .    8  8  8  0  16  0  16 16 16 16     0     0       y       .
0xb2        TrueColor     24   0   y   .  y    .    8  8  8  0  16  0  16 16 16 16     0     0       y       .
0xe2        DirectColor   24   0   y   .  y    .    8  8  8  0  16  0  16 16 16 16     0     0       y       .
0x102       DirectColor   24   0   y   .  y    .    8  8  8  0  16  0  16 16 16 16     0     0       y       .
0x86        TrueColor     32   0   y   .  y    .    8  8  8  8  24  0  16 16 16 16     0     0       y       .
0xa6        TrueColor     32   0   y   .  y    .    8  8  8  8  24  0  16 16 16 16     0     0       y       .
0xd6        DirectColor   32   0   y   .  y    .    8  8  8  8  24  0  16 16 16 16     0     0       y       .
0xf6        DirectColor   32   0   y   .  y    .    8  8  8  8  24  0  16 16 16 16     0     0       y       .
0x8a        TrueColor     32   0   y   .  y    .    8  8  8  8  24  8  16 16 16 16     0     0       y       .
0xaa        TrueColor     32   0   y   .  y    .    8  8  8  8  24  8  16 16 16 16     0     0       y       .
0xda        DirectColor   32   0   y   .  y    .    8  8  8  8  24  8  16 16 16 16     0     0       y       .
0xfa        DirectColor   32   0   y   .  y    .    8  8  8  8  24  8  16 16 16 16     0     0       y       .
0x82        TrueColor     32   0   y   .  y    .    8  8  8  8  16  0  16 16 16 16     0     0       y       .
0xa2        TrueColor     32   0   y   .  y    .    8  8  8  8  16  0  16 16 16 16     0     0       y       .
0xd2        DirectColor   32   0   y   .  y    .    8  8  8  8  16  0  16 16 16 16     0     0       y       .
0xf2        DirectColor   32   0   y   .  y    .    8  8  8  8  16  0  16 16 16 16     0     0       y       .
0x120       TrueColor     32   0   y   .  y    .    8  8  8  8  24  0   0  0  0  0     0     0       y       .
0x128       TrueColor     32   0   y   .  y    .    8  8  8  8  24  0   0  0  0  0     0     0       y       .
0x122       TrueColor     32   0   y   .  y    .    8  8  8  8  24  8   0  0  0  0     0     0       y       .
0x12a       TrueColor     32   0   y   .  y    .    8  8  8  8  24  8   0  0  0  0     0     0       y       .
0x11e       TrueColor     32   0   y   .  y    .    8  8  8  8  16  0   0  0  0  0     0     0       y       .
0x126       TrueColor     32   0   y   .  y    .    8  8  8  8  16  0   0  0  0  0     0     0       y       .
526 frames in 5.0 seconds = 105.200 FPS

X11 log
[    13.511] (II) vmware(0): Initialized VMWARE_CTRL extension version 0.2
[    13.588] (II) vmware(0): Gallium3D XA version: 2.5.0.
[    13.588] (II) vmware(0): Path of drm device is "/dev/dri/card0".
[    13.588] (II) vmware(0): [DRI2] Setup complete
[    13.588] (II) vmware(0): [DRI2]   DRI driver: vmwgfx
[    14.135] (--) vmware(0): Render acceleration is enabled.
[    14.135] (==) vmware(0): Rendercheck mode is disabled.
[    14.135] (--) vmware(0): Direct rendering (DRI2 3D) is enabled.
[    14.135] (--) vmware(0): Direct rendering (DRI3 3D) is enabled.
[    14.135] (==) vmware(0): Direct presents are disabled.
[    14.135] (==) vmware(0): Hardware only presents are automatic per scanout.
[    14.135] (==) vmware(0): Backing store enabled
[    14.135] (==) vmware(0): Silken mouse enabled
[    14.136] (==) vmware(0): DPMS enabled
[    14.136] (II) Initializing extension Generic Event Extension
[    14.136] (II) Initializing extension SHAPE
[    14.136] (II) Initializing extension MIT-SHM
[    14.136] (II) Initializing extension XInputExtension
[    14.136] (II) Initializing extension XTEST
[    14.137] (II) Initializing extension BIG-REQUESTS
[    14.137] (II) Initializing extension SYNC
[    14.137] (II) Initializing extension XKEYBOARD
[    14.137] (II) Initializing extension XC-MISC
[    14.137] (II) Initializing extension SECURITY
[    14.137] (II) Initializing extension XFIXES
[    14.137] (II) Initializing extension RENDER
[    14.137] (II) Initializing extension RANDR
[    14.138] (II) Initializing extension COMPOSITE
[    14.138] (II) Initializing extension DAMAGE
[    14.138] (II) Initializing extension MIT-SCREEN-SAVER
[    14.138] (II) Initializing extension DOUBLE-BUFFER
[    14.138] (II) Initializing extension RECORD
[    14.138] (II) Initializing extension DPMS
[    14.138] (II) Initializing extension Present
[    14.138] (II) Initializing extension DRI3
[    14.138] (II) Initializing extension X-Resource
[    14.138] (II) Initializing extension XVideo
[    14.139] (II) Initializing extension XVideo-MotionCompensation
[    14.139] (II) Initializing extension GLX
[    14.199] (II) AIGLX: Loaded and initialized vmwgfx
[    14.199] (II) GLX: Initialized DRI2 GL provider for screen 0
[    14.199] (II) Initializing extension XFree86-VidModeExtension
[    14.199] (II) Initializing extension XFree86-DGA
[    14.199] (II) Initializing extension XFree86-DRI
[    14.199] (II) Initializing extension DRI2

[pavel-ruban]

Added some fixes to the old calendar app I noted during last days dev:

• depth buffer wasn't regen with a new size on a canvas size change - so clipping was wrong & resize didn't work
• used blit of intermediate FBO to DriftFX FBO, before it didn't work as it tried to blit the depth bit as well, without depth, blit works just fine.
• added new app window with rotating cube example to demo fps & resize app capabilities
• tried to fight resize canvas flickering as much as I could as you need to dispose & recreate swapchain meaning the frame is lost & it flickers. Tried to use 2 surfaces but its way slower so avoided it, what helped a bit with flicker it to have 2 swapchains for same surface so you can dimishing blanks as chain data is cached longer but due to multithreading it flickers still.

https://github.com/pavel-ruban/javafx-driftfx-opengl-canvas-example/tree/main

https://youtu.be/1NWLpA_bVPQ

I tried to convince team to use this lib but we switched back to SWT unfortunately, 2 main reasons:

• VBox testing is awful & periodic crashes just ruin the work

• flicker issue is also a problem I don't know how to fix completely for now.

  Other than that for other cases the lib worked for me perfectly well, hope those issues will be fixed later so it can be used in commercial projects (eg flickering) & vbox for dev purposes.