Bugs and discussions #55
Replies: 30 comments 19 replies
-
@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. |
Beta Was this translation helpful? Give feedback.
-
@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. |
Beta Was this translation helpful? Give feedback.
-
@husker-dev found one memory leak source thanks to my profiler 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 |
Beta Was this translation helpful? Give feedback.
-
@streamingdv I'll see what's wrong tomorrow/the day after tomorrow |
Beta Was this translation helpful? Give feedback.
-
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
With all these Canvas types after the 70 iterations I found some Texture packages lying around in memory e.g.
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
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. |
Beta Was this translation helpful? Give feedback.
-
@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 |
Beta Was this translation helpful? Give feedback.
-
@streamingdv |
Beta Was this translation helpful? Give feedback.
-
@husker-dev sure |
Beta Was this translation helpful? Give feedback.
-
@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.
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 |
Beta Was this translation helpful? Give feedback.
-
I've fixed the flickering on all platforms, but I can't test AsyncSharedCanvasImpl yet. Will test it tomorrow on Linux |
Beta Was this translation helpful? Give feedback.
-
@husker-dev I have several Windows devices, 2 Linux devices and one Mac. So whenever you need help to test something let me know. |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
@husker-dev okay I see, thanks for the information. Will keep testing once you have applied the changes. |
Beta Was this translation helpful? Give feedback.
-
@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). |
Beta Was this translation helpful? Give feedback.
-
During the day I will add the same functionality to other Canvas implementations |
Beta Was this translation helpful? Give feedback.
-
@husker-dev how exactly are you testing? I mainly test with this application https://github.com/streamingdv/OpenGLFXMem and I have to admit that I'm not sure if this is a problem with OpenGLFX, OpenGL in general, JavaFX or something else. The problem is, if I produce a lot of OpenGLFX canvas elements very fast, (disposing it all the time of course) even without a memory profiler, I can see the memory in the taskmanager grow until it needs several gigabytes and until the application finally crashes because it ran out of memory. I found some interesting posts but not sure if they are related https://stackoverflow.com/a/8335478/2298490 https://stackoverflow.com/q/9770063/2298490 https://community.khronos.org/t/opengl-textures-and-memory-leaks/107089/2 I just want to find out what exactly makes the memory grow and grow. In the profiler I still see the D3DTextureData but I'm not sure if they are even the root cause of the problem because the amount of memory my test application needs after a few "create/ dispose" iterations don't match the few 1000 bytes data of D3DTextureData elements. I assume something native is creating this memory as I can't find anything suspicious in my profiler. I'm out of ideas so far. |
Beta Was this translation helpful? Give feedback.
-
@streamingdv |
Beta Was this translation helpful? Give feedback.
-
@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. |
Beta Was this translation helpful? Give feedback.
-
@streamingdv I think it’s impossible to fix this, because it affects LWJGL sources and possibly the operating system. |
Beta Was this translation helpful? Give feedback.
-
But I fixed a lot of other memory issues, and almost completely rewrote Async/BlitCanvasImpl for better performance |
Beta Was this translation helpful? Give feedback.
-
@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 👍 |
Beta Was this translation helpful? Give feedback.
-
I noticed that this problem does not exist on macOS. Apparently it depends on the platform |
Beta Was this translation helpful? Give feedback.
-
I have relased a new version, it will be available soon via maven central |
Beta Was this translation helpful? Give feedback.
-
@husker-dev the new version seems to work fine. Will need some more testing but overall it looks good. |
Beta Was this translation helpful? Give feedback.
-
@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 |
Beta Was this translation helpful? Give feedback.
-
@husker-dev feedback in regards to the newest version 4.0.5.
|
Beta Was this translation helpful? Give feedback.
-
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? |
Beta Was this translation helpful? Give feedback.
-
@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 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? |
Beta Was this translation helpful? Give feedback.
-
Chat about bugs, features and question
Beta Was this translation helpful? Give feedback.
All reactions