Bugs and discussions

[husker-dev]

Chat about bugs, features and question

[husker-dev]

@streamingdv your PR will work, but will not solve the problem with extra rendering. I'll see what can be done about this, but a little later.

[streamingdv]

@husker-dev yeah no worries, this was not meant to be a final solution. I just want to use the YourKit profiler in combination with my test application to check for possible leaks.

[streamingdv]

@husker-dev found one memory leak source thanks to my profiler

streamingdv@0862a07

It also looks a lot better now

However there is still one leak, I let me test program run 50 times and you can see that there is still some prism texture data element lying around which can't be garbage collected (D3DTextureData). According to my profiler the source of this data is in NVDXInteropCanvasImpl.

Any ideas? Maybe the fxD3DTexture which needs to be released? Currently I have no idea.

Will continue testing with other pipelines like Software and OpenGL pipeline

[husker-dev]

@streamingdv
It's very strange that D3DTextureData remains in memory. When you call dispose() on a texture, it must be disposed of along with it.

I'll see what's wrong tomorrow/the day after tomorrow

[streamingdv]

Some follow up information and short summary of the current situation, I continued tested with my current setup (with the fixes applied in my fork) and I can't 100% reproduce the issue with the Texture anymore. Maybe the mistake was on my side, my test program removed and re-added a new Canvas element 70 times, there are still some Texture objects lying around but less then 70 (usually between 20 - max 50). I tested with

• BlitCanvasImpl
• NVDXInteropCanvasImpl
• SharedCanvasImpl

With all these Canvas types after the 70 iterations I found some Texture packages lying around in memory e.g.

ES2TextureData
SWArgbPreTexture
D3DTextureData

Not sure if this is really a leak or if they can be garbage collected at some point, in my opionion there should not be any leftovers after gc collector kicked in after the 70 iterations. I would consider this as potential leak and it seems under certain conditions Texture elements can't be fully garbage collected. Maybe it has something to do with how fast I dispose the canvas (after every 1500ms) in my test app.

I also performed the same test with the async counter parts of the canvas elements, the result was somehow similar I would say. The only thing I noticed is that AsyncBlitCanvasImpl has some problems to be re-instantiated once a AsyncBlitCanvasImpl was disposed. When I dispose the first AsyncBlitCanvasImpl, I get following exception when I re-instantiate the next AsyncBlitCanvasImpl

java.lang.IllegalStateException: There is no OpenGL context current in the current thread.
	at org.lwjgl.opengl.GL.createCapabilities(GL.java:382)
	at org.lwjgl.opengl.GL.createCapabilities(GL.java:311)
	at org.lwjgl.opengl.GL.createCapabilities(GL.java:295)
	at com.huskerdev.openglfx.lwjgl.LWJGLExecutor.initGLFunctions(LWJGLExecutor.kt:15)
	at com.huskerdev.openglfx.canvas.implementations.async.AsyncBlitCanvasImpl$initializeThread$1.invoke(AsyncBlitCanvasImpl.kt:60)
	at com.huskerdev.openglfx.canvas.implementations.async.AsyncBlitCanvasImpl$initializeThread$1.invoke(AsyncBlitCanvasImpl.kt:57)
	at kotlin.concurrent.ThreadsKt$thread$thread$1.run(Thread.kt:30)

If I'm not disposing the AsyncBlitCanvasImpl I don't get this exception. Did not further investigate this issue yet.

Edit: I can confirm that the the texture leak can be reproduced with 100% leaked Textures when the canvas is disposed too fast, e.g. create a canvas and dispose it after 500ms. I know not a very realistic example but still a potential leak. Not sure why though.

[husker-dev]

Can this profiler show where does these objects still in use? I think it is something with JavaFX internal caching.
As for testing - I have added fxTexture.contentsNotUseful() in NVDXInteropCanvasImpl disposing. Can you test it?

[streamingdv]

This contentsNotUseful will throw an error

java.lang.IllegalStateException: Resource obsoleted too many times

It could be an internal JavaFX cache problem, I'm still not yet sure what keeps holding a reference to this texture

[streamingdv]

@husker-dev actually it seems to be cached internally in JavaFX, but it is actually not a Texture but "TextureData" in case of d3d D3DTextureData it seems to be cached somewhere in the com.sun.prism.impl.Disposer

Not sure of how much of a deal this is as it seems to have not a very huge impact on the memory, e.g. I performed a test and the memory raised from 200mb to ~3.3gb but I disposed and re-created a Canvas element every 100ms, 10.000 times. This is not a very realistic scenrio but just proofs that some minor things are leaking. I don't know if it has a bigger impact if you are actually rendering something on the canvas, which I'm not in my test application.

One interesting side fact is that I was able to reproduce the

"java.lang.IllegalStateException: There is no OpenGL context current in the current thread."

with the NVDXInteropCanvasImpl (but only 3 times upon 10.000 re-creation iterations). The error was thrown here

at com.huskerdev.openglfx.lwjgl.LWJGLExecutor.initGLFunctions(LWJGLExecutor.kt:15)

Within the AsyncBlitCanvasImpl, as reported, the issue is reproducible every time though.

[streamingdv]

@husker-dev the issue can even be reproduced if you just keep resizing the Window, if you have the task manager open you can watch the memory grow while you resizing the Application Window. And it's again the TextureData somehow cached inside the com.sun.prism.impl.Disposer. I think you have to check with a profiler yourself to track down the issue, I will check if there is anything more I can find out.

[streamingdv]

Just some thoughts, I started to debug the whole dispose scenario and it seems it has something to do with the disposing of the texture. I'm basically just guessing here but maybe the problem is related to the fact that you are replacing the native texture pointer with your own, this pointer (pResource) is afterwards used in the D3DRecord which has a dispose method, since we replaced the pResource it could lead to a potential problems with the garage collection (but maybe not).

I also debuged the Disposer class and I can see that the method addRecord was called with the Record of D3DTextureData which basically stores the value and it's reference in a HashTable but for whatever reason the disposeUnreachables method in this Disposer class will never remove this records as it seems it will never be marked as "unreachable".

[streamingdv]

@husker-dev as you are basically refactoring the lib in regards of the modules I think it's better if you apply the changes directly, I saw that you have added now the dipose check in the NGGLCanvas which is a better place then mine but in order to fix one part of the memory leak please don't forget to stop the AnimationTimer like here

streamingdv@0862a07

[husker-dev]

@streamingdv
Can you reate a PR with streamingdv@0862a07?

[streamingdv]

@husker-dev sure

#58

[streamingdv]

@husker-dev feedback (not related to memory leak)

I currently test a lot and so I always find some new bugs. I know you are currently refactoring a lot but some of these refactorings destroyed the functionlity of the OpenGLFX.

1. The following line just produces an exception

java.lang.IllegalStateException: Resource obsoleted too many times

2. After this push something doesn't work anymore correctly. Whenever I try to resize my Window it will turn into a black frame and I can never render anything again (even when I create a new Canvas). When I not resize the Window and just dispose it it will also not render anything again even after I created a new Canvas, This seems to happen only with the NVDXInteropCanvasImpl but not with AsyncNVDXInteropCanvasImpl.

3. I saw that you have added the dispose check in the renderContent method of NGGLCanvas but this still doesn't avoid the NullPointerException in the drawResultTexture of GLCanvas. For me there must be some kind of threading issue as this fix is still required on my end to not get the exception.

Edit: point 3. Was wrong. It was a user error, I didposed the canvas in the render callback. Pull request to fix 1. and 2. is out

[husker-dev]

I've fixed the flickering on all platforms, but I can't test AsyncSharedCanvasImpl yet. Will test it tomorrow on Linux

[streamingdv]

@husker-dev I have several Windows devices, 2 Linux devices and one Mac. So whenever you need help to test something let me know.

[husker-dev]

There were some problems with cleaning up resources in Async canvas. Contexts must be deleted in the same threads where they are current. This also applies to their resources. The current implementation most likely does not completely remove contexts from video memory.

I'll try to solve this problem over the weekend

[streamingdv]

@husker-dev okay I see, thanks for the information. Will keep testing once you have applied the changes.

[husker-dev]

@streamingdv I've added some changes to AsyncNVDXInterop. If you have time, try looking at memory usage. In theory, those objects should now be deleted.

I checked without a profiler - the memory always remained about the same (VRAM and RAM).

[husker-dev]

During the day I will add the same functionality to other Canvas implementations

[streamingdv]

@husker-dev can you check with my example project as well? It automatically recreates the canvas, how fast can be modified. I don't think I have anything special logic within the app, just modify the gradle to use the 4.0.1 version and set the recreation time to something about 50ms and the application will crash within a few minutes. I'm just curious.

[husker-dev]

@streamingdv
I looked into the source of the problem when creating large numbers of GLCanvas quickly. Everything stops at the GL.createCapabilities() function of LWJGL - when this function is called, a thread somewhere inside is synchronized, which slows down execution in our case.
When creating a large number of GLCanvas, we simply queue a large number of threads, which are processed slowly and accumulate in memory, causing a crash.

I think it’s impossible to fix this, because it affects LWJGL sources and possibly the operating system.

[husker-dev]

But I fixed a lot of other memory issues, and almost completely rewrote Async/BlitCanvasImpl for better performance

[streamingdv]

@husker-dev yes that's what I thought and that's what some of the posts I found on the internet are saying. This is probably also some kind of an OpenGL specific thing, native memory seems not to be able to be released as fast we create the Canvas elements. It's also not at all a realistic scenario and if it works in a productive environment that's of course more than good enough. Will test the latest changes on my test systems. If I find out something I will let you know. The lib is so awesome and it's really a game changer to me 👍

[husker-dev]

I noticed that this problem does not exist on macOS. Apparently it depends on the platform

[husker-dev]

I have relased a new version, it will be available soon via maven central

[streamingdv]

@husker-dev the new version seems to work fine. Will need some more testing but overall it looks good.
For the future work I really strongly recommend to use some kind of profiler to monitor memory and CPU usage to measure method invocation and execution time/ cost. It's actually very easy to track down performance bottlenecks, unnecessary object creations (e.g. for fine tuning garbage collection), and potential memory leaks. Especially as this library aims for the best performance I think it would definitely be a good idea. Again, great work 👍

[streamingdv]

@husker-dev minor issue, the AsyncSharedCanvasImpl still flickers/ blink upon resizing on Windows (not tested on Linux yet). Please look at the attached video (other async canvas elements are not flickering upon resizing). I use the newest version of OpenGLFX which is 4.0.2

https://drive.google.com/file/d/1SwymTTd0pJMHFv02ZC3C07hxafmmHNs2/view?usp=sharing

[husker-dev]

I'll see what's wrong

[husker-dev]

Found a bug - forgot to call glFinish before passing information between threads.
Theoretically, before this fix, the previous frame was always the output :)

[husker-dev]

I'm going to release a new version.
I made some changes to the project architecture so the creation of GLCanvas will change from

GLCanvas.create(...)

to

new GLCanvas(...)

[streamingdv]

@husker-dev feedback in regards to the newest version 4.0.5.

• Async Software canvas crashes upon start on Linux
• Async OpenGL Canvas still has some strange artefacts upon resizing on Linux (works fine on Windows though). The effect was minimized with version 4.0.3 because before it was much worse. Here is a video of this strange effect
• There is also an interesting side effect, whenever I try to dispose this async OpenGL canvas on Linux I encountered some kind of deadlock situation. The dispose method never returned and was stuck forever. All I did was resizing the canvas and close the streaming window (which triggers a dispose). It doesn't happen all the time but it occurs often.

[husker-dev]

@streamingdv Thank you very much for testing!

• I'm aware of the Blit Canvas crashing on Linux. This is due to the lack of context change. This implementation was intended for cases where JavaFX renders via SW. In this case there are no problems.

• About strange glitches - I noticed them, but thought it was a problem with my device or the Mesa3D library. I'll see what I can do about this.

• I will try to fix disposing too.

[streamingdv]

Ah okay I see so this means the async blit canvas only works correctly when only software pipeline is enabled? But that's not the case wit stands blit canvas?

[husker-dev]

@streamingdv
Could you test the master branch on Linux?
It is better to run the built-in example, where you can perform some actions using hotkeys:

./gradlew runLWJGL

What I would like to know:

• Resizing behavior
• Recreation (on my device with Mesa3D after disposing the canvas, JavaFX stops rendering the window untill it moved or resized)
• MSAA and FXAA performance

---

I don't have a Linux device with a graphics card, so I can't test it properly.

[streamingdv]

Yes I can test it tomorrow 👍

[streamingdv]

@husker-dev some feedback in regards to testing on my Linux machine with Nvidea GPU. I used

./gradlew runLWJGL

• Resizing: still produces some strange artefacts when resizing, similiar to the video I already provided before
• Same behaviour on my machine, rendering stops but when I move or resize the Window it works again
• MSAA and FXAA performance, I could not note any difference. I always had constant 60 fps, did not matter if I disabled or enabled MSAA/ FXAA

Anything else I need to test in more details? It was just a quick check on my dev machine.

[streamingdv]

And it seems the Async canvas has some micro stuttering problem, when I disable the async rendering it runs a lot smoother. I can't find anything any fps drops but from the visual aspect you can cleary see the stuttering, which is not present with the standard Canvas.

[streamingdv]

@husker-dev just wondering if you encountered the micro stuttering with the async canvas as well at some point? I have disabled this feature in my application now as it doesn't seem to work reliable across different PCs.

I have also implemented now a different rendering approach which uses Vulkan rendering via libplacebo in a glfw window (via lwjgl API). I can't use javafx in this window though but I used some native UI components rendered via libplacebo for my few onscreen buttons. Best part is that via vulkan ffmpeg decoding libplacebo supports zero copy rendering on the glfw surface. I have plans to make my example java wrapper for libplacebo open source soon.

[streamingdv]

@husker-dev just another question and it's a bit off topic but as you are the expert I just wanted to here your thoughts, I was a bit researching of how to achieve a zero copy approach for rendering my hardware video AVFrames from ffmpeg via OpenGL. As I'm not yet very experienced OpenGL user I did some research and at least on Linux it is theoretically possible via the vaapi hardware decoder which means I could potentially render my decoded hardware video frames from my GPU memory directly onto a surface without copying it into the main memory.

I'm in contact with one the the Chiaki devs and he pointed me in the correct direction, so in theory it would work via EGLImage like that

https://github.com/streetpea/chiaki4deck/pull/98/files#diff-60660f571de143f23e1f2575ee8f83df4c6a4d0712720ed41d07ad404a8f67bb

or here an example project

https://github.com/fmor/demo_ffmpeg_vaapi_gl/tree/master#decode-and-render-to-texture-

Would that be possible with OpenGLFX somehow? As far as I understand the source code of OpenGLFX yet I think yes even without touching the lib ad all can happen withing the rendering callback?

[husker-dev]

I have never worked with ffmpeg or other video decoding libraries, but from the description it doesn’t look very difficult.
As I understand, EGLImage is an object in the graphics card memory that can be used by several applications. Openglfx has an alternative - IOSurface but only for macOS.

It will be very difficult to you to implement this feature without changing the library code. (But of course you can try)

I'll put this feature off for a bit (until about the weekend) since learning these things will take some time. I'll work on it once I fix some problems and add planned little features.

[streamingdv]

@husker-dev it's not yet very important I just play around with some stuff and as you have definetly more know how than me I just wantedt to ask what you think about that. Yes I think you have understood it correctly, at least that's also my understanding.

[streamingdv]

@husker-dev porting my app to macOS at the moment and I saw that it seems there is no support for Intel Macs? Is that correct? I just receive following error on my Intel Mac

Exception in thread "JavaFX Application Thread" java.lang.UnsatisfiedLinkError: /private/var/folders/y6/cmzf4w391hqb64n708_vnsfm0000gn/T/com-huskerdev-openglfx-natives-openglfx.dylib: dlopen(/private/var/folders/y6/cmzf4w391hqb64n708_vnsfm0000gn/T/com-huskerdev-openglfx-natives-openglfx.dylib, 0x0001): tried: '/private/var/folders/y6/cmzf4w391hqb64n708_vnsfm0000gn/T/com-huskerdev-openglfx-natives-openglfx.dylib' (mach-o file, but is an incompatible architecture (have (arm64), need (x86_64h)))

So I assume there is no native lib for Intel Macs? Is that correct? If so I will disable the option to select the OpenGLFX renderer on Intel Macs for now and just use the libplacebo Vulkan/ Metal renderer.

[husker-dev]

@streamingdv
This is strange because I compiled the universal library for both ARM64 and x86.

I'll see what I can do with it.